Re: [patch] Lno branch merge part 8 -- canonical induction variable creation

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

Hello,

> On Sun, 22 Aug 2004, Zdenek Dvorak wrote:
> > first let me emphasize one thing that you probably missed (as some
> > of your comments suggest):  The ivcanon patch does not have problems
> > with semantics of overflow of signed arithmetics, since all induction
> > variables it creates are unsigned.
> 
> My apologies for confusing the issue.
> 
> In RTH's review of your patch
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00364.html
> 
> > > +   type = TREE_TYPE (niter);
> > > +   niter = fold (build (PLUS_EXPR, type,
> > > + 		       niter, convert (type, integer_one_node)));
> >
> > I don't see anything in canonicalize_loop_induction_variables
> > that ensures that this addition doesn't overflow.  If TYPE is
> > unsigned I guess it doesn't matter -- with the predecrement
> > and EQ_EXPR we can iterate 2**32 times with a 32-bit variable.
> > But other parts of the compiler are going to do the wrong thing
> > if TYPE is signed.
> 
> 
> To which you had originally replied
> http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00383.html
> > Even in signed type it works exactly the same way.
> 
> 
> Which sparked this entire goose chase.  Clearly by now, you understand
> that, by default, signed and unsigned overflow don't behave the same way.
> Instead of this inflamatory comment, what you really should have said
> was:
> 
> The code in number_of_iterations_cond in tree-ssa-loop-niter.c that
> initially determines the number of iterations, always returns an
> unsigned result:
> >  /* Count the number of iterations.  */
> >  niter_type = unsigned_type_for (type);
> 
> And this type is used for creating the canonical induction variables.
> Hence at the hunk queried by r~, the type is always guaranteed to be
> unsigned, and hence overflow is well defined.

I am really sorry for the confussion; this fact occured to me only after
I sent the mail (and I noted it in the next followup).

Anyway -- could you please respond to the rest of my mail?  I would
really like to have all the confusion around -f[wt]rapv we have created
cleared up.

Zdenek