On Fri, 27 Feb 2009, Dave Korn wrote: > Richard Guenther wrote: > > > It's definitely safer. Still we have to carefully modify existing > > code to deal with the new tree codes as most of it carelessly > > transitiones old codes to new trees. For example re-associating > > (a +/nv b) + c to a +/nv (b + c) is wrong. > > Yes, of course we have to take care when processing the new codes, but the > wonderful thing that I was pointing out is that none of the current > fold/simplify code will attempt to reassociate the new codes at first, until > it's been explicitly taught about them, whereas if we had used a flag it would > plough straight ahead under the misapprehension that it understood the > semantics of the tree code, that's all.
Correct. > Anyway, your plan gets a big thumbs-up from me. The noobs will be endlessly > glad when signed ints start overflowing in the way they'd hoped, and the Heh - this will only happen if the frontend does not indicate there isn't overflow with signed operations. Which of course it will unless you specify -fwrapv. > fortran-wielding-heavy-duty-massive-array-number-crunching-academic types can > use a commandline option to make sure they still get their "loop optimiser > assumes your index won't overflow so loop must terminate" optimisations, won't > they? Yes. -fwrapv also shouldn't be as bad as we can re-instantiate the no-wrapping operation codes during value-range analysis. Richard.
