Aaron Sawdey <acsaw...@linux.ibm.com> writes:
>> On Nov 20, 2020, at 4:57 AM, Aaron Sawdey via Gcc-patches
>> <gcc-patches@gcc.gnu.org> wrote:
>>
>>
>>> On Nov 20, 2020, at 3:55 AM, Richard Sandiford <richard.sandif...@arm.com>
>>> wrote:
>>>
>>> acsawdey--- via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>>>> @@ -16767,7 +16768,7 @@ loc_descriptor (rtx rtl, machine_mode mode,
>>>> break;
>>>>
>>>> case CONST_INT:
>>>> - if (mode != VOIDmode && mode != BLKmode)
>>>> + if (mode != VOIDmode && mode != BLKmode && !OPAQUE_MODE_P (mode))
>>>> {
>>>> int_mode = as_a <scalar_int_mode> (mode);
>>>> loc_result = address_of_int_loc_descriptor (GET_MODE_SIZE (int_mode),
>>>
>>> I realise I'm asking this about something that already appears to handle
>>> BLKmode CONST_INTs (?!), but this is the one change in the patch I
>>> struggled with. Why do we see a CONST_INT that allegedly has an
>>> opaque mode? It feels like something has gone wrong further up the
>>> call chain.
>>>
>>> This might still be the expedient fix for whatever is happening,
>>> but I think it deserves a comment at least.
>>>
>>> The rest looks good to me FWIW.
>>>
>>> Richard
>>
>> I should look at this again — since I originally put that in, I switched the
>> target
>> portion of what I’ve been doing to use an UNSPEC to remove all use of an
>> opaque mode const_int from the rtf. This may not be needed any more.
>
> And as a final addendum — I was able to remove this and the problem I saw
> before did not come back, probably because UNSPEC is used to hide all
> constants so we never see any opaque type or mode constants, which is a
> good thing.
Great. The patch is OK without that hunk and with the gen_type nit fixed.
Thanks,
Richard
