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. 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. jeff