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
