Re: [PATCH 01/13] [APX EGPR] middle-end: Add insn argument to base_reg_class

[Vladimir Makarov <vmakarov@redhat.com>]

On 9/10/23 00:49, Hongyu Wang wrote:
> Vladimir Makarov via Gcc-patches <gcc-patches@gcc.gnu.org> 于2023年9月9日周六 01:04写道：
>>
>> On 8/31/23 04:20, Hongyu Wang wrote:
>>> @@ -2542,6 +2542,8 @@ the code of the immediately enclosing expression (@code{MEM} for the top level
>>>    of an address, @code{ADDRESS} for something that occurs in an
>>>    @code{address_operand}).  @var{index_code} is the code of the corresponding
>>>    index expression if @var{outer_code} is @code{PLUS}; @code{SCRATCH} otherwise.
>>> +@code{insn} indicates insn specific base register class should be subset
>>> +of the original base register class.
>>>    @end defmac
>> I'd prefer more general description of 'insn' argument for the macros.
>> Something like that:
>>
>> @code{insn} can be used to define an insn-specific base register class.
>>
> Sure, will adjust in the V2 patch.
> Also, currently we reuse the old macro MODE_CODE_BASE_REG_CLASS, do
> you think we need a new macro like INSN_BASE_REG_CLASS as other
> parameters are actually unused? Then we don't need to change other
> targets like avr/gcn.
>
I thought about this too.  Using new macros would be definitely worth to 
add, especially when you are already adding INSN_INDEX_REG_CLASS.

The names INSN_BASE_REG_CLASS instead of MODE_CODE_BASE_REG_CLASS and 
REGNO_OK_FOR_INSN_BASE_P instead of REGNO_MODE_CODE_OK_FOR_BASE_P are ok 
for me too.

When you submit the v2 patch, I'll review the RA part as soon as 
possible (actually I already looked at this) and most probably give my 
approval for the RA part because I prefer you current approach for RA 
instead of introducing new memory constraints.