> 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.
Aaron Sawdey, Ph.D. saw...@linux.ibm.com
IBM Linux on POWER Toolchain
