On Thu, 7 Nov 2013, Kenneth Zadeck wrote: > On 11/07/2013 01:07 PM, Richard Sandiford wrote: > > Kenneth Zadeck <zad...@naturalbridge.com> writes: > > > I very strongly disagree with this. The standard needs to be high than > > > "does it pass the test suite." > > > > > > What we are introducing is a case where the program will behave one way > > > with optimization and another way without it. While, this is always > > > true for timing dependent code, it is pretty rare for math. We should > > > always tread carefully when doing that, and the excuse that it is > > > "cleaner" does not, in my mind, fit the bill. > > If it makes you feel any better (probably not), this was already true > > for !SHIFT_COUNT_TRUNCATED targets. The tree level would then not do > > any truncation, whereas as you said before, all real targets do in practice. > > And that affected many of the main targets, including x86_64, powerpc, > > z/Series, ARM, etc. > > > > (And the tree level has to do _something_. "unsigned int i = 1 << 32;" > > must compile with default options, even if the behaviour's undefined. > > Only rtl has the luxury of being able to punt.) > > > > Although you could go out of your way to try to make the undefined > > behaviour match what the target instructions would do, that'd be a > > lot of work, especially for cases that are implemented using library > > calls. And there's a lot to be said for making the behaviour > > consistent across targets, which is what removing the truncation > > from the tree level does. > > > > Things are different at the rtl level because there a backend can > > legitimately exploit the behaviour of the shift instructions when > > implementing optabs. And optabs.c itself does this when creating > > doubleword shifts. So at the rtl level we can only optimise out-of-range > > shifts if we're sure what the target would do. > > > > Thanks, > > Richard > I understand that i have lost this battle. But the truth is that this is a > symptom of a fairly deep problem with GCC: the people who work at the tree > level feel that it really is wrong or unclean to understand the target when > they do transformations. With the exception of the vectorizer, the tree level > is maintained revels in it's lack of understanding of the target. This is the > primary reason that optimizations like sign extension elimination are done so > poorly in gcc - you really do need to know what the target can do for free > and the cost of what it can't do. Only then can you push the code in a > direction where you do good.
That's a completely different issue than to try to match target behavior when constant folding an expression with undefined behavior. Richard.
