Comments on: Tamarin Tracing Internals IV: Trace Optimization

By: Indonesia Furniture Handicraft Wholesale Marketplace

Indonesia Furniture Handicraft Wholesale Marketplace — Sat, 05 Jun 2010 04:09:20 +0000

Thanks for this, I’m still learning about what you share here.

By: dce results

dce results — Thu, 19 Jun 2008 19:24:39 +0000

[...] for this is mostly in the nanojit/ directory. Keep in mind that a trace is always straight-line codehttp://blog.mozilla.com/dmandelin/2008/05/28/tamarin-tracing-internals-iv-trace-optimization/Prep roundup: Fagbemi dominates at sectionals Marshfield News HeraldEAU CLAIRE — Oladipo Fagbemi [...]

By: dmandelin

dmandelin — Fri, 30 May 2008 18:15:00 +0000

Cool. I think the spill code is hard to understand just because there aren’t standard algorithms for it (vs. say, CSE), so I don’t have much of a starting idea of how it works. One thing I did notice about the design of the register allocator is that it tries to assign the same register to a result as the one it will get used in later, which tends to save copies. This is nice-coalescing can also avoid those copies but I think is much too expensive for TT.

Thanks for the tip, although what tripped me the most at first was that you have to read the code generation code backward-but I’m getting used to that now.

By: Rick Reitmaier

Rick Reitmaier — Fri, 30 May 2008 16:01:10 +0000

Compiling LIR bottom-up has a number of advantages (like you’ve
mentioned) and we think it makes for a smaller assembler, which
is a major factor for TT.

Like you’ve highlighted walking through the Assembler code can be a bit
confusing. Another way of thinking about it is that the current set of
Reservation’s forms a contract that must be met by downstream code
(i.e. code already generated).

For example we’ve generated :

add eax,ebx

Now if we want to use eax we have to make sure it gets
loaded, so we rematerialize it, like so

mov eax,ebp[-8]
add eax,ebx

Now we’re free to use eax for another instruction:

sub eax,ebx
mov eax,ebp[-8]
add eax,ebx

A really nice part of this flow is that we don’t have to worry
about how eax in the sub gets populated (likewise when we
generated the add, we didn’t know that eax would be loaded
from the stack).

This approach tends to produce reasonable code, in that
remats typically happen close to uses without additional
book-keeping or extra passes, and spills (if needed) happen
at the point when the value is produced.

tip: reading the code as its generated (i.e. backwards) can
be easily accomplished by modifying the 1st if statement in
Assembler::output() to :
if (0 && _outputCache)

By: Andreas

Andreas — Thu, 29 May 2008 06:56:15 +0000

I think a lot of the configuration values (XJUMPS, BLKS, EXITS) are a result of Ed and his team experimenting with different strategies to contain the code explosion through tail duplication, and to steer what gets recorded and extended when.

If you set the XJUMPS limit to 2, for example, you “outerlined” traces (folding of the outer nested loop into the inner loop), which we use a lot in our trees to deal with simple nested loop.

Without having looked at the code recently, I would assume MAX_EXITS might be an attempted to limit tail duplication as a result of trying to inline outer method scopes. If you start recording in method f and you backtrack into the outer scope (method) g, that transition back into the outer scope (return) might spawn a number of side exits (one for each other scope f can be called from). Since TT does support recording into outer scopes (which we do not in Hotpath), they have to somehow limit this growth.