On Fri, 2006-02-24 at 18:42 +0100, Sebastian Pop wrote: > 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. One possibility that isn't as drastic would be to add one to the TYPE_MAX_VALUE of the inner type, then see if the result fits in the outer type. Perhaps also limiting that test to unsigned types.
Then again, that could just be papering over the problem; I really don't know this code anywhere near enough to know what a good solution will be. jeff
