Question about make_extraction() in combine.c

[Michael Eager]

On 11/21/2018 08:33 AM, Segher Boessenkool wrote:
> On Tue, Nov 20, 2018 at 10:07:35AM -0800, Michael Eager wrote:
>> The internal RTL should not be dictating what the target arch can or
>> cannot implement.  Reload should insert any needed conversions,
>> especially ones which narrow the size.
> 
> Well, that depends.  A zero_extract of mem is only defined for byte_mode,
> just like SET is only defined for VOIDmode (on the SET itself, not its
> args).  Because this is guaranteed, nothing in GCC ever needs to check
> this.  That is the theory of course; in reality quite a few targets have
> used other modes for the mem in a zero_extract, and this seems to have
> mostly worked.

This restriction on zero_extract MEM args (and only MEM) seems to be
completely arbitrary.  What is it about the operation of extracting a
bit field which makes it dependent on the memory access size?

The value of SET is VOIDmode, in that it has no value.   Not sure what
your point is here.

> As another example, closer by, an extract length of 0 is not allowed
> either, for zero_extract.  And this *did* cause problems recently.

This is a restriction which does make sense.  It isn't clear what
the value of a zero length field is, or how to represent it.  If
something is undefined, then there is a strong argument for making is
invalid.  (Are there architectures which have instructions which extract
a zero length bit field?  I doubt it.)

> Why was it documented as requiring byte mode?  Was this changed, just
> the documentation was not updated?

Ancient history.  As Jeff said, perhaps an architectural requirement of
VAX or m68k.  This wasn't changed, as far as I'm aware.

-- 
Michael Eager    eager@eagerm.com
1960 Park Blvd., Palo Alto, CA 94306