Richard Kenner wrote:
> Just to make sure I've dotted the i's and crossed the t's, this is not
> what's happening when we hang in VRP when compiling a-textio.
>
> We convert the incoming object from natural___XDLU_0___2147483647
> into its base type, perform the addition in the base type, then
> convert back to XDLU_0_2147483647.
>
> The above is exactly what I thought everybody agrees is and should be
> happening, so I'm confused by your "this is not what's happening"
> comment above.
So if I understand correctly, if we can prove that the operation does
not overflow in natural___XDLU_0___2147483647, then there is no need
of a cast to the base type and back.
chrec_convert is checking for non overflowing sequences before
removing a cast, and that is missing from the aggressive convert.
Aggressive convert has been intentionally implemented this way because
the conservative chrec_convert has caused performance regressions (see
sixtrack slowdowns from last August).
A patch like the following would solve the problem too, but will
introduce performance regressions... so I'm not sure that it is a good
solution.
Index: tree-chrec.c
===================================================================
--- tree-chrec.c (revision 111416)
+++ tree-chrec.c (working copy)
@@ -1202,6 +1202,8 @@ chrec_convert_aggressive (tree type, tre
{
tree inner_type, left, right, lc, rc;
+ return chrec_convert (type, chrec, NULL_TREE);
+
if (automatically_generated_chrec_p (chrec)
|| TREE_CODE (chrec) != POLYNOMIAL_CHREC)
return NULL_TREE;
