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


Ignore:
Timestamp:
May 14, 2011 2:23:13 PM (3 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{{{