Question about make_extraction() in combine.c

Jeff Law law@redhat.com
Wed Nov 21 00:49:00 GMT 2018


On 11/20/18 11:07 AM, Michael Eager wrote:
> 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 do correctness tests for m68k via qemu.  Essentially verifying it
still bootstraps:-)  Just pass along a git formatted patch and I can
throw it into the tester.

jeff



More information about the Gcc mailing list