This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ivopts vs. garbage collection
- From: Michael Matz <matz at suse dot de>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: Jeff Law <law at redhat dot com>, Ian Lance Taylor <iant at golang dot org>, GCC Development <gcc at gcc dot gnu dot org>, Lynn Boger <laboger at linux dot vnet dot ibm dot com>
- Date: Mon, 11 Jan 2016 19:00:14 +0100 (CET)
- Subject: Re: ivopts vs. garbage collection
- Authentication-results: sourceware.org; auth=none
- References: <CAOyqgcWphMUdS7pMyo9STBChnimJEWm0Ou+wmRtFM2Z500BiJg at mail dot gmail dot com> <568D3217 dot 6050802 at redhat dot com> <CAFiYyc0L0rduOMicug53bxx3-n2DGF-_1D1bEGw4oDWo3wo4vw at mail dot gmail dot com>
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.