Question about make_extraction() in combine.c

[Michael Eager]

On 11/21/18 11:47, Segher Boessenkool wrote:
> On Wed, Nov 21, 2018 at 08:52:21AM -0800, Michael Eager wrote:
>> 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?
> 
> If the mode is required to be byte_mode, then all code dealing with it
> can assume it to be byte_mode.  Without first having to check it, and
> without having to handle other modes.

Essentially all other RTL operations place no restriction on mode.
If there are no arbitrary mode restrictions, then no checking is
required.

> 
>> The value of SET is VOIDmode, in that it has no value.   Not sure what
>> your point is here.
> 
> See above.
> 
>>> 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.)
> 
> It doesn't matter if you (or I, or anyone) think it makes sense; the rules
> are the rules.  If you want to change the rules, then post a patch.

These are not immutable rules delivered by some deity.  Rules which
have no discernible value or purpose can and should be changed.

A patch is being tested.

>>> 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.
> 
> So a mem in a *_extract is still required to be byte_mode you say? >
> I don't think we can change this in the documentation without reviewing
> all code that deals with *_extract to see if this will work :-/

Have at it.

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