In today's meeting we first discussed the new annotations I proposed for our future dynamic compilation framework. Then we resumed the discussion about lazy stitching. 1. New Annotations One thing that came up was how we want to treat pointers or structures. The decision if we want to treat data pointed to by a constant pointer as also constant seems to an orthogonal issue and we can choose the semantics that we like. One thing that was brought up, however, was the following: t = d-> foo; keep_const(t share_const) where d is a dynamic pointer. If the programmer knows that t will always evaluate to the same value, the annotation above will do what he wants. However, we might also want to avoid reevaluated the lookup d->foo each time in setup. Consensus was that we probably can handle some simple cases like the one above right away, but what we might really want could be a more general framework that allows us to talk about more general invariants. Another point was that the annotation of dynamic branches as lazy should also be guided by the real cost laziness will cause compared to an eager approach. Some feedback from data generated at run time could be used to decide when eagerness pays off. Caching more than one value and having more constants we might have to think more about cache effects. We have to think about how we can produce these mutliple versions in a way that they are close to the text (close branches). We also want to make the check that we are overflowing the area where code is stiched as cheap as possible. Also the BTA and the stitcher should give the programmer feedback about the constants and their values to assess how well the intuition about possible values of run time constants were. One detail that came up was the following: P1: t = d->foo; P2: make_const(t); B In the template generated for B t will not be referenced. If it is not used afterwards, it will be dead at P2 and dead code elimination might eliminate the load at P1 alltogether. Hemce, we have to introduce some markers (as when entering a region) to prevent this from happening. 2. Lazy stitching The main point we discussed was how we could/should restore the runtime constants when in the fixup code. --There were some suggestions in the previous meeting of building the fixup code (that built up the rtcs) dynamically, but this method seems expensive (building a 64-bit value can take a lot of instructions, and we have to store each of these instructions into the new fixup-code we're building, so we don't save on storing overhead), and it's not clear how we can cheaply avoid clobbering the values that were in the registers used for the build (remember that we not only have to restore runtime constants, we also have to "remap" stitched code values in the registers) --The method Matthai suggested basically uses the fact that the runtime constants that need to be restored in the fixup for a branch Bij are those that are live across the branch. We store these values in a table indexed by the current context when the other side of the branch is taken (and we stitch the branch to fixup code), and stitch an instruction just before the branch that builds the current context into a scratch register. The fixup code then just needs to load off the table (using the context from the scratch register) to restore runtime constant context.