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

[Richard Sandiford <rdsandiford at googlemail dot com>]

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