| 36 | {{{ |

| 37 | I64[ Sp + n ] = "stack" |

| 38 | |

| 39 | I64[ Base + n ] = "base" |

| 40 | |

| 41 | I64[ Hp + n ] = "heap" |

| 42 | I64[ R1 + n ] = "heap" |

| 43 | |

| 44 | I64[ I64[Sp + n] ] = "heap" |

| 45 | I64[ I64[Sp + n] + m ] = "heap" |

| 46 | |

| 47 | I64[ I64[R1 + n] ] = "heap" |

| 48 | I64[ I64[R1 + n] + m ] = "heap" |

| 49 | I64[ 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 | {{{ |

| 55 | I64[Sp + R1[n]] |

| 56 | }}} |

| 57 | |

| 58 | is "stack", not "heap". |

| 59 | |

| 60 | == How to Track TBAA information == |

| 61 | |

| 62 | Really 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 | {{{ |

| 65 | I64[ Sp ... ] = ... |

| 66 | }}} |

| 67 | |

| 68 | That 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 | {{{ |

| 71 | x = Sp + 8 |

| 72 | I64[x] = ... |

| 73 | }}} |

| 74 | |

| 75 | And 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 | |