Re: Validity of SUBREG+AND-imm transformations

[Richard Sandiford <rdsandiford at googlemail dot com>]

Kyrill Tkachov <kyrylo.tkachov@foss.arm.com> writes:
> 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.

Yeah.  It'd be nice to retain a predictable mode if possible.  One of
the things on my todo list for GCC 7 is to automatically generate a
function that gives you the correct shift amount mode for a particular
shift value mode, so that there's a lot less guessing.  (It's one of the
main blockers to having modes on CONST_INTs.)

Thanks,
Richard