shift/extract SHIFT_COUNT_TRUNCATED combine bug

[Segher Boessenkool]

On Wed, Jan 14, 2015 at 10:10:24AM +0100, Richard Biener wrote:
> On Tue, Jan 13, 2015 at 6:38 PM, Segher Boessenkool
> <segher@kernel.crashing.org> wrote:
> > On Tue, Jan 13, 2015 at 10:51:27AM +0100, Richard Biener wrote:
> >> IMHO SHIFT_COUNT_TRUNCATED should be removed and instead
> >> backends should provide shift patterns with a (and:QI ...) for the
> >> shift amount which simply will omit that operation if suitable.
> >
> > Note that that catches less though, e.g. in
> >
> > int f(int x, int n) { return x << ((2*n) & 31); }
> >
> > without SHIFT_COUNT_TRUNCATED it will try to match an AND with 30,
> > not with 31.
> 
> But even with SHIFT_COUNT_TRUNCATED you cannot omit the
> and as it clears the LSB.

The 2*n already does that.

Before combine, we have something like

	t1 = n << 1
	t2 = t1 & 30
	ret = x << t2

(it actually has some register copies to more temporaries), and on
SHIFT_COUNT_TRUNCATED targets where the first two insns don't combine,
e.g. m32r, currently combine ends up with

	t1 = n << 1
	ret = x << t1

while it doesn't without SHIFT_COUNT_TRUNCATED if you only have a
x << (n & 31)  pattern.

I'm all for eradicating SHIFT_COUNT_TRUNCATED; just pointing out that
it is not trivial to fully replace (just the important, obvious cases
are easy).


Segher