On Fri, 27 Feb 2009, Dave Korn wrote: > Richard Guenther wrote: > > On Fri, 27 Feb 2009, Zdenek Dvorak wrote: > > >> introducing new codes seems like a bad idea to me. There are many > >> places that do not care about the distinction between PLUS_EXPR and > >> PLUSV_EXPR, and handling both cases will complicate the code (see eg. > >> the problems caused by introducing POINTER_PLUS_EXPR vs PLUS_EXPR > >> distinction). Why not just use a flag to mark the operation as > >> non-overflowing? > > > > I obviously thought about this. The issue with using a flag is > > that there is no convenient place to stick it and that it makes > > the distinction between the two variants less visible. Consider > > the folding routines that take split trees for a start. > > > > IMHO using new tree-codes is much less complicated than carrying > > around flags. I did consider putting flags on the tree code > > itself, but that isn't going to make the changes easier either. > > I think it's probably a far safer design too. > > If you suddenly introduce a new semantic for an existing code, suddenly > every current check for that tree code becomes a potential bug site that has > to be manually inspected to see if it's overflow-sensitive or not and > therefore whether it needs to test the new flag or not; people who don't know > about the new flag will carry on adding code that processes those tree codes > without knowing to test the flag; and the bugs that do arise will be hard to > find and result in silent bad codegen. > > If OTOH you add new tree codes, the meaning will be explicit, nobody using > them can be under any misapprehension about the overflow semantics, nobody can > forget to check the flag, and any places where they should be handled but > aren't will very quickly draw themselves to our attention by ICEing, or if > they don't will simply fall back to the safe option of not doing any > processing on a tree code that they don't recognize; that might lead to > pessimal code, but it shouldn't generate incorrect code.
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. Richard.
