Re: Pros and cons of high-level intermediate languages

nfsun!gchamber@uunet.UU.NET (Glenn Chambers) writes:
>In the interests of getting the obvious out of the way, the easiest
>optimization is to allocate global and static local variables that point
>to GC'able objects in a special data area that the GC system knows about.


>Adding a '#pragma flush-registers' to deal with the optimizer seems to be
>the only actual extension to the language that I can see.


>Is there some simpler and cheaper technique I'm unaware of?


Yes, if you're using a conservative collector and your optimizer is "not
too smart" (but this raises the bar on how smart the optimizer must be).


Consider the following:


extern volatile void * __gc_sink; /* A reserved name not appearing in
                                                                          std-compliant programs. */
#define _GC_USE(x) __gc_sink = (void *) (x)


After *every* use of a pointer 'x' known (by the translator to C) to be
garbage collected, insert '_GC_USE(x)'. The optimizer does not get to
eliminate these, but (other than keeping a register for x) other
optimization proceeds relatively unhindered. In a post-pass over the
assembly language, or in the assembler itself (or object file generator
itself) the additional stores are stripped out of the instruction stream,
leaving only some register pressure (either from the address of __gc_sink,
or for the things stored into it).


The way that we (Hans Boehm and I) see this going wrong is if "x" is
reconstituted (say, from other induction variables) at the _GC_USE instead
of kept in a register. This is definitely not out of the question, but I
don't think this is in common practice yet. By not being excessively
clever with the location of _GC_USE (say, by placing it at the end of a
live range, instead of at each use site) you reduce the risk of this
happening (I think).


Long-term, what Moss et alii are doing is probably best, though it is
tough going.


David Chase
Sun
--

Return to the comp.compilers page.
Search the comp.compilers archives again.