Hi, On Fri, 8 Jan 2016, Richard Biener wrote:
> > The only solution here is for ivopts to keep a pointer to the array, > > not a pointer to some location near, but outside of the array. > > Yes, the solution is to make IVOPTs not do this (eventually controlled > by a parameter because clearly it thinks doing this is beneficial > cost-wise). Well, that's a hack. A solution is to design something that works generally for garbage collected languages with such requirements instead of arbitrarily limiting transformations here and there. It could be something like the notion of derived pointers, where the base pointer needs to stay alive as long as the derived pointers are. All potential GC points where a derived pointer is alive also needs to have the base pointer be alive (they could explicitely add uses of the base pointers, or alternatively anthing computing liveness needs to deal with this). For normal transformation that don't deal with explicit liveness sets (i.e. most of our SSA transforms) it's enough if the instruction creating the derived pointer from the base can't be looked through, i.e. is an optimization barrier. Ciao, Michael.
