Changes between Version 22 and Version 23 of Commentary/Compiler/NewCodeGenStupidity


Ignore:
Timestamp:
Apr 27, 2011 9:49:21 AM (4 years ago)
Author:
ezyang
Comment:

more items

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGenStupidity

    v22 v23  
    225225
    226226The call area for the jump in cbG is using an extra word on the stack, but in fact Sp + 0 at the entry of the function immediately becomes dead after the assignment, so we ought to be able to save some space in our layout. Simon Marlow suggests we distinguish between the return address and the old call area; need to talk to SPJ about fixing this.
     227
     228== Heap and R1 aliasing ==
     229
     230CONFIRMED. Values on the heap and values from R1 don't necessarily clobber
     231each other.  allocDynClosure seems like a pretty safe bet they
     232don't.  But is this true in general?
     233
     234        _s14Y::F64 = F64[_s1uN::I32 + 8];
     235        _s152::F64 = F64[_s1uN::I32 + 16];
     236        _s156::F64 = F64[_s1uN::I32 + 24];
     237        _s15a::F64 = F64[_s1uN::I32 + 32];
     238        _s15e::F64 = F64[_s1uN::I32 + 40];
     239        _s15i::F64 = F64[_s1uN::I32 + 48];
     240        _s15m::F64 = F64[_s1uN::I32 + 56];
     241        _c39O::I32 = Hp - 60;
     242        // calling allocDynClosure
     243        // allocDynClosure
     244        I32[Hp - 60] = sat_s1uQ_info;
     245        F64[Hp - 52] = _s14Y::F64;
     246        F64[Hp - 44] = _s152::F64;
     247        F64[Hp - 36] = _s156::F64;
     248        F64[Hp - 28] = _s15a::F64;
     249        F64[Hp - 20] = _s15e::F64;
     250        F64[Hp - 12] = _s15i::F64;
     251        F64[Hp - 4] = _s15m::F64;
     252
     253== Double temp-use ==
     254
     255
     256CONFIRMED. Here's a curious piece of code that fails to get inlined (from `cc004`):
     257
     258{{{
     259        _sG5::I32 = I32[Sp + 48];
     260        I32[Sp - 4] = _sG5::I32;
     261}}}
     262
     263Why is that? Because the temp gets reused later on:
     264
     265{{{
     266    u1bF:
     267        Sp = Sp + 56;
     268        // outOfLine here
     269        R1 = a13_rAk_closure;
     270        I32[Sp - 8] = _sG5::I32;
     271}}}
     272
     273In this case, we want more aggressive inlining because there are too
     274many temps and they're going to have to get spilled to the stack anyway.
     275IS THAT TRUE?  For comparison's sake, the old codegen doesn't appear to
     276do any rewriting, because it just reuses the call area.
     277
     278Actually, I think this is a case of spill/reload silliness.