Changes between Version 28 and Version 29 of Commentary/Compiler/NewCodeGenStupidity


Ignore:
Timestamp:
May 14, 2011 2:23:13 PM (4 years ago)
Author:
ezyang
Comment:

updates

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/NewCodeGenStupidity

    v28 v29  
    224224}}}
    225225
    226 The 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.
     226The 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; however, since this can also happen for the return parameters from call areas, we need a more general scheme.
     227
     228After I discussed this with SPJ, we've decided that we need to teach the stack layout how to handle partial conflicts. There is a complication here, in that if we do this naively, the interference graph will blow up (since, rather than conflicting call areas, we now have conflicting words of call areas.) Simon suggested that we bound the amount of conflicts we track: either up to 3 or conflict with everything (in which case we just place the area as far down as necessary rather than try to be clever.) I plan on doing this once I understand the current layout code...
    227229
    228230== Heap and R1 aliasing ==
    229231
    230 CONFIRMED. Values on the heap and values from R1 don't necessarily clobber
     232FIXED. Values on the heap and values from R1 don't necessarily clobber
    231233each other.  allocDynClosure seems like a pretty safe bet they
    232 don't.  But is this true in general?
     234don't.  But is this true in general? ANSWER: Memory writes with
     235Hp are always new allocations, so they don't clobber anything.
    233236
    234237{{{
     
    280283== Stupid spills ==
    281284
    282 If something is already in memory, why do we have to spill it again?
     285CONFIRMED. If something is already in memory, why do we have to spill it again?
    283286
    284287{{{
     
    385388}}}
    386389
    387 The trouble is that the spiller doesn't know that the old call area is also valid game for locations that variables can live in. I thought maybe we could have the stack layout engine coalesce these, but them we need to know about when memory changes (since the old area will get written over.) This will also interact in strange ways with when we try to overlap areas.
     390The trouble is that the spiller doesn't know that the old call area is also valid game for locations that variables can live in. So, the solution is to rewrite the spiller to know about existing incoming memory locations. Make sure that this information gets to the stack layout engine when we do partial layouts (it should automatically notice, but double check!)
    388391
    389392== Noppy proc-points ==
    390393
    391 Consider
     394CONFIRMED. Consider
    392395
    393396{{{