Re: Question about make_extraction() in combine.c

[Jeff Law <law at redhat dot com>]

On 11/21/18 9: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.
Right.

> 
> As another example, closer by, an extract length of 0 is not allowed
> either, for zero_extract.  And this *did* cause problems recently.
Very true.  I don't doubt there's still corner cases that haven't been
well documented.

> 
> Why was it documented as requiring byte mode?  Was this changed, just
> the documentation was not updated?
I don't think it was ever documented why byte mode was required, merely
that it was required.  I can recall stumbling over it in the early/mid
90s.  I've got references to the byte requirement going back to early
1992 in my archives.

After some wandering of those archives, folks were clearly worried about
the extv/insv insns reading/writing beyond the boundary of the current
object.  If you restrict memory ops to QImode, then you resolve that
problem.

But we're unlikely to get a definitive answer here.


I think the real question is can we reasonably lift the restriction.



Jeff