Changes between Version 16 and Version 17 of Commentary/Compiler/Backends/LLVM/Alias


Ignore:
Timestamp:
Jan 18, 2012 11:27:25 PM (2 years ago)
Author:
dterei
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/Compiler/Backends/LLVM/Alias

    v16 v17  
    3434'''Answer''' (Simon Marlow): Sp[] and Hp[] never alias, R[] never aliases with Sp[], and that's about it. 
    3535 
     36{{{ 
     37I64[ Sp + n ] = "stack" 
     38 
     39I64[ Base + n ] = "base" 
     40 
     41I64[ Hp + n ] = "heap" 
     42I64[ R1 + n ] = "heap" 
     43 
     44I64[ I64[Sp + n]  ] = "heap" 
     45I64[ I64[Sp + n] + m  ] = "heap" 
     46 
     47I64[ I64[R1 + n] ] = "heap" 
     48I64[ I64[R1 + n] + m ] = "heap" 
     49I64[ I64[Sp + n] +  I64 [R1 + n] ] = "heap" 
     50}}} 
     51 
     52''' Simon''': As long as it propagates properly, such that every F(Sp) is a stack pointer, where F() is any expression context except a dereference.  That is, we better be sure that 
     53 
     54{{{ 
     55I64[Sp + R1[n]] 
     56}}} 
     57 
     58is "stack", not "heap". 
     59 
     60== How to Track TBAA information == 
     61 
     62Really to be sound and support Cmm in full we would need to track and propagate TBAA information. It's Types after all! At the moment we don't. We simply rely on the fact that the Cmm code generated for loads and stores is nearly always in the form of: 
     63 
     64{{{ 
     65I64[ Sp ... ] = ... 
     66}}} 
     67 
     68That is to say, it has the values it depends on for the pointer derivation in-lined in the load or store expression. It is very rarely of the form: 
     69 
     70{{{ 
     71x = Sp + 8 
     72I64[x] = ... 
     73}}} 
     74 
     75And when it is, 'it is' (unconfirmed) always deriving a "heap" pointer, "stack" pointers are always of the in-line variety. This assumption if true allows us to look at just a store or load in isolation to properly Type it. 
     76 
    3677== LLVM type system == 
    3778