Re: [PATCH] Fix IVOPTs problem

[Richard Guenther <richard dot guenther at gmail dot com>]

On 8/25/05, Jeffrey A Law <law@redhat.com> wrote:
> 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?  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?
> 
> Or do we want to go with a simple solution, then install the
> ARRAY_REF patch, then work on carrying the aliasing information
> in the TARGET_MEM_REF expression.
> 
> I've got no strong opinions on how we want to deal with this
> for 4.2, mostly because I haven't thought through how much
> work it will be to carry all the aliasing information on the
> TARGET_MEM_REF and use that in the operand scanning code.

I guess for 4.2 the best way is to wait for the aliasing-branch to be
created and see how this will all fit together.  For 4.1 I'm not sure
we can not get a situation like with the array patch, but I'm not sure
the other way around, too.  The question is, will we possibly silently
generate wrong code if this case occours in a checking-disabled
compiler?

Richard.