[Patch] [Aarch64] PR rtl-optimization/87763 - this patch fixes gcc.target/aarch64/lsl_asr_sbfiz.c

Richard Earnshaw (lists) Richard.Earnshaw@arm.com
Fri Apr 26 22:38:00 GMT 2019

On 26/04/2019 22:54, Jeff Law wrote:
> On 4/26/19 3:09 PM, Segher Boessenkool wrote:
>> On Fri, Apr 26, 2019 at 06:06:37PM +0100, Richard Earnshaw (lists) wrote:
>>> On 26/04/2019 17:08, Jeff Law wrote:
>>>>> So is that valid RTL (DI extract of SI value)?  Why wouldn't that just
>>>>> use a paradoxical subreg to widen the register being extracted?
>>>> [ ... ]
>>>> And for completeness, the patch also survived regression testing
>>>> aarch64be where it fixes the lsl_asr_sbfiz test.
>>>> I think the big question here is whether or not we consider this valid RTL.
>>> The documentation for sign_extract says:
>>> @item (sign_extract:@var{m} @var{loc} @var{size} @var{pos})
>>> ...
>>> If @var{loc} is in memory, its mode must be a single-byte integer mode.
>>> If @var{loc} is in a register, the mode to use is specified by the
>>> operand of the @code{insv} or @code{extv} pattern
>>> (@pxref{Standard Names}) and is usually a full-word integer mode,
>>> which is the default if none is specified.
>>> So it's a little unclear to me whether the mode of loc is ignored for
>>> registers, or if it must match the mode of the extract.
>> It must use the mode the extv pattern says to use.   But you don't *have*
>> such a pattern here, you have extv<mode> instead.
> Right.
>> It makes most sense if the mode for extv<mode> is the same both in and out
>> (it has only one mode in the pattern name, to start with), and for
>> sign_extract to be similar.  The docs aren't quite clear, but defining it
>> to have multiple modes doesn't really solve anything afaics, subregs work
>> just fine here?
> You'd have to scatter them in the MD file.  That's generally frowned upon.

A subreg on a reg is fine (which is what we'd have in this specific
case).  It's when the subreg gets left on something else (other than a
mem) when the problems start.

> My argument is that we have very clear semantics here.  We're taking a
> field from an object in a mode.  We zero or sign extract it to the mode
> of the destination.   Two modes actually make reasonable sense here.
> Think of it like zero_extend or sign_extend, but for a bitfield.

This certainly makes sense, but the cases are more general since the
extraction might produce a result that is either wider or narrower than
the original reg being acted upon.


More information about the Gcc-patches mailing list