Re: [PATCH] Rewrite store-motion and invariant motion to use an alias-oracle

[Richard Guenther <rguenther at suse dot de>]

On Wed, 19 Mar 2008, Zdenek Dvorak wrote:

> Hi,
> 
> > > it seems do you do not actually reapply the extension as you promise
> > > in the comment above?
> > 
> > The original expression is subtracted (comb->elts[i].val) and the
> > expansion is applied to the leaf expressions via the following hunk.
> > 
> > *************** tree_to_aff_combination (tree expr, tree
> > *** 338,344 ****
> >         break;
> >       }
> >     
> > !   aff_combination_elt (comb, type, expr);
> >   }
> >   
> >   /* Creates EXPR + ELT * SCALE in TYPE.  EXPR is taken from affine
> > --- 338,344 ----
> >         break;
> >       }
> >     
> > !   aff_combination_elt (comb, type, fold_convert (type, expr));
> >   }
> >   
> >   /* Creates EXPR + ELT * SCALE in TYPE.  EXPR is taken from affine
> > 
> > 
> > (maybe there's a better place to do it, but it really needs to be
> > done on the leaf of expanded expressions).
> 
> right... still, this seems to be equivalent to transforming
> 
> unsigned char a, b;
> 
> (unsigned long) (a + b) to (unsigned long) a + (unsigned long) b
> 
> which is incorrect when a + b overflows?

Yes.  I was assuming the affine combinations are all address arithmetic
where overflow is undefined or rather does not occur.

So the other way to fix this would be not to insert the conversions
to comb->type in the first place.  It is really the same problem
we have with extra conversions for POINTER_PLUS_EXPR on lp64 archs
when we have ptr + int.  Maybe there is a more elegant solution to
handle loop-33.c on lp64.

Of course unfortunately the ICE that blocks the patch in the first
place is present with and without that change :/

Richard.