This is the mail archive of the
mailing list for the GCC project.
Re: [wide-int] Remove SHIFT_COUNT_TRUNCATED uses at tree/gimple level
- From: Richard Biener <rguenther at suse dot de>
- To: Kenneth Zadeck <zadeck at naturalbridge dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "mikestump at comcast dot net" <mikestump at comcast dot net>, rdsandiford at googlemail dot com
- Date: Fri, 8 Nov 2013 09:42:05 +0100 (CET)
- Subject: Re: [wide-int] Remove SHIFT_COUNT_TRUNCATED uses at tree/gimple level
- Authentication-results: sourceware.org; auth=none
- References: <87ob5xji5i dot fsf at talisman dot default> <527AEB2F dot 6080808 at naturalbridge dot com> <87vc04it8l dot fsf at talisman dot default> <2FA3EC3C-BD01-4CB5-AEA7-37225101C3DF at naturalbridge dot com> <8761s4hypy dot fsf at talisman dot default> <527BD8DF dot 7080102 at naturalbridge dot com>
On Thu, 7 Nov 2013, Kenneth Zadeck wrote:
> On 11/07/2013 01:07 PM, Richard Sandiford wrote:
> > Kenneth Zadeck <email@example.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.