Re: Question about make_extraction() in combine.c

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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

> >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 :-/


Segher



[Index of Archives]     [Linux C Programming]     [Linux Kernel]     [eCos]     [Fedora Development]     [Fedora Announce]     [Autoconf]     [The DWARVES Debugging Tools]     [Yosemite Campsites]     [Yosemite News]     [Linux GCC]

  Powered by Linux