Re: [patch] for PRs 27639 and 26719

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

Hello,

> > How do subtypes wrap, if at all?  If you have an unsigned [0, 7], what
> > is the result of u + 8?  What is the result of u + 256 (if the base type
> > was unsigned char)?  Is it defined?
> 
> Hi Richard, in Ada arithmetic on subtypes is defined by: convert to base
> type, perform arithmetic, convert back.  The language requires a check
> that the value is in the range of the subtype, with an exception being
> raised if not (the Ada front-end inserts this check except when it can
> prove that it is not needed).
> 
> (A) u + 8.  The front-end would generate:
> 
>    tmp = ((unsigned char) u) + 8;
>    if (tmp > 7)
>       goto raise_exception;
>    u = (subtype) tmp;
> 
> VRP could deduce that tmp>7 is always true and the final code would be:
> 
>    goto raise_exception;
> 
> So the front-end will never generate such an expression, in fact it will
> never generate any arithmetic directly in u at all.  However, in general
> the compiler (in this case the back-end) could reasonably generate
> arithmetic directly in u if it could prove that the component expressions
> and the result are in the range of the subtype.  So if you ever see an
> expression like:
> 	u = u + 8;
> then that should imply that the compiler has proved that u+8 is in the range
> of the subtype (which is not the case here).

thanks for your explanation.  So the most correct solution seems to be
to make nowrap_type_p return true for subtypes and modify
scev_probably_wraps_p to handle the value ranges correctly (at the
moment, scev_probably_wraps_p only works correctly if the value range of
the type matches its precision).  Also, one would need to fix the
optimizations that may produce out of bounds expressions in the subtypes
(most notably ivopts, which is fairly straightforward, but there may be
other optimizations with the similar problems).

The other possibility is to stay conservative and simply never produce
arithmetic operations in subtypes.  If dom and fold are clever enough to eliminate
unnecessary casts to subtypes in the middle of the expressions, e.g., optimizing

tmp1 = (supertype) a;
tmp2 = tmp1 + 1;
a = (subtype) tmp2;
tmp3 = (supertype) a;
tmp4 = tmp3 * 2;
a = (subtype) tmp4;

into

tmp1 = (supertype) a;
tmp2 = tmp1 + 1;
tmp4 = tmp2 * 2;
a = (subtype) tmp4;

the results should not turn out much different from the ones obtained by
the first possibility.

Zdenek