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 Fri, Aug 06, 2004 at 11:18:00AM +0200, Zdenek Dvorak wrote:
> > the various bit being?  I must admit that on various places in loop
> > optimizer we break this assumption in just about every possible way,
> > and I have never seen a problem with it.
> 
> Fold certainly cares.

isn't this wrong?  I mean, the fact that signed expressions do not
overflow is C language specific, so using it with other frontends might
cause problems.

Also, preserving it at all times may be difficult. At most places
in ivopts I cannot really say whether there is an overflow or not
when I need to express an old iv using a new one.  Which does not
directly cause problems -- the arithmetics just produces the correct
results, regardless of overflows, but if someone looks at type
information and wants to make a conclusions about overflows using it,
it won't work.  So I would have to introduce a system of (no-op) casts to
and from unsigned types (which may also cause undefined behavior,
perhaps -- is a result of cast from too large unsigned to signed defined?)

It seems to me that it would be cleaner to have a flag (say
TREE_DOESNT_OVERFLOW), that frontends would set up on operations for
that they are sure that they do not overflow (signed ones in C, maybe
just all operations in some more restrictive languages).  Then
optimizers can produce possibly overflowing operations regardless of the
type.  The worst think that could then happen is that some optimization
would kill this information unnecessarily, but we should not have any
correctness problems.

Zdenek