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

Jeff Law law@redhat.com
Fri Apr 26 23:54:00 GMT 2019

On 4/26/19 4:30 PM, Richard Earnshaw (lists) wrote:
>>> 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.
I've generally found that we're better off avoiding (subreg (reg)) when
we reasonably can inside MD patterns.  But I won't object if you'd
prefer to go with a subreg style solution.

>> 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.
True, but aarch64 promotes just about everything to at least SImode.  So
supporting QI/HI destinations doesn't seem to make sense.  Supporting
different modes on the source could make sense, though I suspect the
vast majority of the benefit will be from SImode & DImode.

How do you want to proceed?   I'm just trying to move things along and
will happily step aside if you'd prefer to go with something like
Steve's approach.


More information about the Gcc-patches mailing list