On 2006-12-31 08:06:56 -0500, Robert Dewar wrote: > Vincent Lefevre wrote: > >On 2006-12-30 20:07:09 -0500, Robert Dewar wrote: > >> In my view, this comparison optimization should not have been put in > >> without justification given that it clearly does affect the semantics > >> of real code. Indeed if you really see code like > >> > >> if (a - 10 < 20) > >> > >> in place of > >> > >> if (a < 30) > >> > >> a very likely explanation is that you are deliberately doing something > >> strange with wrap around, and should leave it alone. > > > >I disagree concerning your "very likely explanation". This code > >may come from the use of macros, in which case this has nothing > >to do with wrap around. > > Sorry, my "you" was unclear, I meant you as in a human not you as > in a compiler. Yes, if the code comes from macros, it might well > be in advertent, and of course inadvertent overflow, never mind > potential overflow can be hidden in macros this way.
This is still not clear. If I write a - 10 < 20 (where a is signed), this implicitly assumes that a - 10 cannot overflow; in particular, when writing macros, I take care of that. So, from this point of view, the optimization is safe as long as -ftrav is not used. > My point was that if you see this in a source program, it is in > fact a possible candidiate for code that can be destroyed by > the optimization. Well, only for non-portable code (i.e. code based on wrap). I also suppose that this kind of code is used only to check for overflows. > And that's the trouble, this is an optimization which does improve > performance, but may destroy existing code, and the very example > you gave to talk about improved performance is also a nice case > of showing why it may destroy performance. In fact the wrap > around range test is a standard idiom for "hand optimization" > of range tests. Yes, and the lack of optimization would be even worse. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)
