This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Question about make_extraction() in combine.c
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