Question about make_extraction() in combine.c

[Michael Eager]

On 11/18/2018 08:14 AM, Jeff Law wrote:
> On 11/18/18 8:44 AM, Michael Eager wrote:
>> On 11/16/18 14:50, Segher Boessenkool wrote:
>>> Hi!
>>>
>>> On Wed, Nov 14, 2018 at 11:22:58AM -0800, Michael Eager wrote:
>>>> The (mem:SI) is converted to (mem:QI).
>>>>
>>>> The return from make_extract() is
>>>>  Â Â Â  (zero_extract:SI (mem:QI (reg/v/f:SI 50 [ gp ]))
>>>>  Â Â Â Â Â Â  (const_int 1 [0x1])
>>>>  Â Â Â Â Â Â  (const_int 2 [0x2]))
>>>>
>>>> The target has an instruction pattern for zero_extract, but it matches
>>>> SI values, not QI.  So the instruction which implements a test of a bit
>>>> flag is never generated.
>>>
>>> The RTL documentation says:
>>>
>>>  Â Â  If @var{loc} is in memory, its mode must be a single-byte integer
>>> mode.
>>>
>>> But obviously various ports use other modes, too.  I wonder if that ever
>>> worked well.
>>
>> Thanks.  I hadn't noticed this.
>>
>> Does anyone have any idea why there is a restriction on the mode?
>> Other instruction patterns don't place arbitrary restriction on the
>> memory access mode.
> Not offhand.   BUt it's been around for a long time (at least since the
> early 90s).  I stumbled over it several times through the years.  It
> could well be an artifact of the m68k or the vax.

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.

I have a patch which removes this conversion.  Works for my target.  I 
built and ran 'make check' for x86 with no additional failures.  I don't 
have a VAX or M68K sitting around to test.  :-)

I can submit the patch and remove the restriction from the docs, but I 
have no way of telling that this doesn't break (or deoptimize) some 
other target.


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