Re: [wide-int] Remove SHIFT_COUNT_TRUNCATED uses at tree/gimple level

[Richard Biener <rguenther at suse dot de>]

On Thu, 7 Nov 2013, Kenneth Zadeck wrote:

> On 11/07/2013 01:07 PM, Richard Sandiford wrote:
> > Kenneth Zadeck <zadeck@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.