This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][RFC] Prune incoming pointer points-to sets
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "Richard Guenther" <rguenther at suse dot de>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Tue, 13 May 2008 13:29:39 -0400
- Subject: Re: [PATCH][RFC] Prune incoming pointer points-to sets
- References: <Pine.LNX.4.64.0805131519270.4134@zhemvz.fhfr.qr>
On Tue, May 13, 2008 at 9:25 AM, Richard Guenther <rguenther@suse.de> wrote:
>
> This patch pruns the points-to sets of incoming pointers to not include
> non-global variables. This fixes for example PR36201 where otherwise
> <result> is aliased if it is marked addressable by NRV.
WFM.
>
> Unfortunately this exposes a weakness in PRE (and/or SCCVN) which doesn't
> handle the situation of a mismatch in the number of VOPs well (I filed
> PR36230 for this). Still this looks like an obvious and important
> improvement (I'll throw this patch to the benchmarks tonight).
Ya.
I'm not surprised about this.
It's still not taken care of completely in my PRE conversion either.
> Bootstrapped and tested on x86_64-unknown-linux-gnu (with
> gcc.dg/tree-ssa/loadpre1[45].c regressing).
>
> (In 4.2 we had NONLOCAL artificial vars - I'm not sure if for the
> purpose of tracking incoming pointer sets more precisely - and it looks
> like re-introducing such may be the better approach?)
>
> Danny, do you remember about the NONLOCAL stuff and what it was supposed
> to do?
>
So, NONLOCAL was introduced exactly to track the set of the nonlocal
variables that could be accessed, as you have guessed.
This provides better information than we have.
The problem is that the nonlocal set can grow to massive proportions,
and was getting propagated around
Nowadays, with better pointer equivalence opts, this should happen
less, but it will still happen.
As such, it is probably better to solve nonlocal as a separate
propagation just to be safe.
Note that i've experimented with nonlocal for LLVM in interprocedural
mode, and it really is a time sink.