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
