Re: [PATCH] Fix IVOPTs problem

[Zdenek Dvorak <rakdver at atrey dot karlin dot mff dot cuni dot cz>]

Hello,

> On Thu, 2005-08-25 at 10:48 +0200, Richard Guenther wrote:
> 
> > 
> > I think we cannot avoid loosing aliasing precision without directly
> > storing the necessary information to re-construct aliasing information
> > at get_tmr_operands time.
> It certainly needs to be stored in the TARGET_MEM_REF expression, I
> don't know when the best time to record this information will be.
> 
> So I think we have a few questions we need to answer, some are
> shorter term, some are long term.
> 
> First, for 4.1, do we think we can get into similar situation where
> IVOPTs changes the computed aliasing information, but without the
> patch to muck around with ARRAY_REFs?

I think it should not happen.  The problem can appear only if a
reference that accesses only part of subvars for a given object
is rewritten by ivopts.  However, ivopts will only do so if the
address is an induction variable, which may only be the case if the
reference contains ARRAY_REF or INDIRECT_REF.  Currently we however
expect all the subvars to be accessed by such references, thus the
problem cannot appear.

That being said, I do not understand our system of representation of
alias analysis results enough to be entirely sure about this.

> If so, then we need a simple
> and safe solution for 4.1.
> 
> 
> Second, for 4.2 and beyond, do we want to first ensure that we
> can attach the aliasing information to the TARGET_MEM_REF and 
> make that a prerequisite for the ARRAY_REF patch?

We definitely should come up with some solution that would enable
us to preserve alias analysis results throughout the optimizations.
Ivopts are not the only pass where we risk losing their precision;
just the one in that I was from the begining firmly trying to avoid
that, leading to greater visibility of the problem (and higher
concentration of hacks).

Zdenek