This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix IVOPTs problem
On Sat, 2005-08-13 at 20:09 +0200, Zdenek Dvorak wrote:
> Hello,
>
> > > > On Fri, 2005-08-05 at 11:48 +0200, Richard Guenther wrote:
> > > > > Compiling gcc.c-torture/execute/20010910-1.c with IVOPTs enabled
> > > > > leads to ssa verification failures because
> > > > > tree-ssa-loop-ivopts.c:rewrite_use does not update ssa form
> > > > > (it calls update_stmt but misses mark_new_vars_to_rename).
> > > > But are the transformations performed by ivopts supposed to
> > > > be changing the aliasing information?
> > >
> > > no, ivopts should not change virtual operands of any statement. So
> > > there is indeed a bug in ivopts, but this is not the right fix.
> >
> > Presumably IVOPTs should not choose &ep as base in this case,
> > but rather &ep.rx_skbuff[0] - or would this be worse in any case?
> > I can only think of the case of a structure with two or more embedded
> > arrays where we could end up with more IV bases than before.
> > Maybe we need to add range information to TMR.
>
> not really. The aliasing information for TMR is taken only from
> TMR_TAG, anything else is irrelevant.
Which, BTW, will turn out to be not-so-good when we have anti-alias
sets.
> The problem is that with subvars,
> there is not an unique tag associated with the memory reference
> (just some set of subvars).
This is because you are accessing multiple pieces of memory. If we had
no reason to keep them distinct, we could use a single tag to group
them, but that loses precision in the general case.
> I am thinking about the solution that
> would not be too hacky.
>
> Zdenek