This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: GC changes

Bernd Schmidt wrote:
> > > We already need a switch to disable GC unfriendly optimizations.
> Which ones would that be?

The rule is: if a memory object may be accessed after an insn, a pointer
to the object(*) must be present in a register or on the stack.

(*) or a more relaxed rule if the GC can handle it: a pointer into the
object must be present.

All optimisations must guarantee this.  In practice, there probably
aren't many optimisations that break.  Only those that offset addresses
(cse, loop, reload?).  It's conceivable that some machine descriptions
might temporarily offset an address unknown to the main compiler code.
E.g. "sub REG,REG,4, jump to REG+4" I can imagine on some hypothetical
RISC chip (Sparc?).

Even a jump to an address _might_ count as a use, if we're dealing with
systems that load code dynamically, but that's getting a bit far fetched.

Making the optimisations safe may amount to lots of extra USE notes.  In
practice the code change should be small.  At worst, you can simply
store the non-offset addresses on the stack before killing them from

> And how can we verify that the generated code is indeed GC friendly?  If it
> can't be verified with a testsuite, such a switch might as well not be there,
> since it won't work in practice.

Unfortunately you have to have test cases which can trigger the wrong
optimisation.  Quite difficult and the failures will be platform
specific.  Checking the registers and stack is quite portable using
setjmp, so a test can use that to ask "do the registers/stack contain a
pointer to OBJECT at this point in the code?".

-- Jamie

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]