On Mon, Jan 11, 2016 at 10:00 AM, Michael Matz <m...@suse.de> wrote: > > 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.
What do you suggest we do for GCC 6? Your suggestion of every derived pointer keeping the base pointer alive sounds too strong to me; it certainly sounds too strong for Go. For Go it should be sufficient to ensure that every derived pointer points within the bounds of the object. Only when a derived pointer points outside of the object (including just after the end of the object) is it necessary to explicitly keep a base pointer alive. It's also not obvious to me that making a pointer transformation into an optimization barrier would be a win overall. For something like ivopts it seems better to simply not introduce the pointer transformation--to apply ivopts only to non-pointers when GC matters (GC matters not only for Go and Java, but also for any C/C++ program using something like the Boehm collector). (I'm still puzzled by the fact that Java has apparently not encountered this problem in all these years.) Ian
