Validity of SUBREG+AND-imm transformations

[Kyrill Tkachov]

On 05/03/16 05:52, Jeff Law wrote:
> On 03/04/2016 09:33 AM, Kyrill Tkachov wrote:
>>
>> On 04/03/16 16:21, Jeff Law wrote:
>>> On 03/04/2016 08:05 AM, Richard Biener wrote:
>>>>> does that mean that the shift amount should be DImode?
>>>>> Seems like a more flexible approach would be for the midend to be able
>>>>> to handle these things...
>>>>
>>>> Or macroize for all integer modes?
>>> That's probably worth exploring.  I wouldn't be at all surprised if it
>>> that turns out to be better than any individual mode,  not just for
>>> arm & aarch64, but would help a variety of targets.
>>>
>>
>> What do you mean by 'macroize' here? Do you mean use iterators to create
>> multple variants of patterns with different
>> modes on the shift amount?
>> I believe we'd still run into the issue at
>> https://gcc.gnu.org/ml/gcc/2016-03/msg00036.html.
> We might, but I would expect the the number of incidences to be fewer.
>
> Essentially we're giving the compiler multiple options when it comes to representation of the shift amount -- allowing the compiler (combine in particular) to use the shift amount in whatever mode is most natural. ie, if the count is 
> sitting in a QI, HI, SI or possibly even a DI register, then it can be used as-is.  No subregs, no zero/sign extensions, or and-imm masking.
>

The RTL documentation for ASHIFT and friends says that the shift amount must be:
"a fixed-point mode or be a constant with mode @code{VOIDmode}; which
mode is determined by the mode called for in the machine description
entry for the left-shift instruction". For example, on the VAX, the mode
of @var{c} is @code{QImode} regardless of @var{m}.

 From what I understand the "ashl" standard name should expand to an ASHIFT with a particular mode for the shift amount.
Currently that's QImode for aarch64.
So whenever combine tries to propagate anything into the shift amount it has to force it into QImode.
I don't see how specifying multiple matching patterns for different modes will help as combine propagates
the and-immediate operation into the shift amounts, creates the awkward subreg and tries to match that.
It won't try different modes on the shift amount to help matching (and from previous discussions I understand
that's not the direction we want combine to take).

I've filed PR 70119 to track this down easier (sourceware archives cut of the thread across months :( )
with example code.

Thanks for the ideas,
Kyrill

> jeff