[PATCH][ARM] Fix broken shift patterns

[Andrew Stubbs]

On 07/10/11 13:37, Paul Brook wrote:
>> Done, and attached.
>
> Ok.
>
> Two changes to the testcase that I'll pre-approve:
> - Add a comment along the lines of
>    /* ARM has shift-and-alu insns.  Depending on the ALU op GCC represents some
>     of these as a left shift, others as a multiply.  Check that we match the
>     right one.  */
> - Also test (a * 64) - b [rsb] and ~(a * 64) [mvn]

Thanks, I've committed the attached.

>> In this case, I believe the hardware simply shifts the the value clean
>> out of the register, and always returns a zero (or maybe -1 for
>> ashiftrt?).
>
> I'm not convinced.  ARM instructions shift modulo 256
> (i.e. a>>  (b&  0xff).  I'm pretty sure anything that gets constant-folded by
> earlier passes will not honor these semantics.

True, but I'm still not sure what the least wrong way to do this might be.

>>> For bonus points we should probably disallow MULT in the arm_shiftsi3
>>> pattern, stop it interacting with the regular mulsi3 pattern in
>>> undesirable ways.
>>
>> How might that be a problem? Is it not the case that canonical forms
>> already deals with this?
>
> Mainly just general principle that having two insns with the same pattern is
> wrong - reload can't flip between them like it can different altrnatives, and
> there's obscure rules about which one wins when both match.

OK, so we'd just need a shift_operator_that_isnt_mult predicate, 
(probably not with that name).

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr50193.patch
Type: text/x-patch
Size: 3496 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20111007/29e13f02/attachment.bin>