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

[Vladimir Makarov <vmakarov@redhat.com>]

On 9/7/23 02:23, Uros Bizjak wrote:
> On Wed, Sep 6, 2023 at 9:43 PM Vladimir Makarov <vmakarov@redhat.com> wrote:
>>
>> On 9/1/23 05:07, Hongyu Wang wrote:
>>>
>> I think the approach proposed by Intel developers is better.  In some way
>> we already use such approach when we pass memory mode to get the base
>> reg class.  Although we could use different memory constraints for
>> different modes when the possible base reg differs for some memory
>> modes.
>>
>> Using special memory constraints probably can be implemented too (I
>> understand attractiveness of such approach for readability of the
>> machine description).  But in my opinion it will require much bigger
>> work in IRA/LRA/reload.  It also significantly slow down RA as we need
>> to process insn constraints for processing each memory in many places
>> (e.g. for calculation of reg classes and costs in IRA).  Still I think
>> there will be a few cases for this approach resulting in a bigger
>> probability of assigning hard reg out of specific base reg class and
>> this will result in additional reloads.
>>
>> So the approach proposed by Intel is ok for me.  Although if x86 maintainers
>> are strongly against this approach and the changes in x86 machine
>> dependent code and Intel developers implement Uros approach, I am
>> ready to review this.  But still I prefer the current Intel developers
>> approach for reasons I mentioned above.
> My above proposal is more or less a wish from a target maintainer PoV.
> Ideally, we would have a bunch of different memory constraints, and a
> target hook that returns corresponding BASE/INDEX reg classes.
> However, I have no idea about the complexity of the implementation in
> the infrastructure part of the compiler.
>
Basically, it needs introducing new hooks which return base and index 
classes from special memory constraints. When we process memory in an 
insn (a lot of places in IRA, LRA,reload) we should consider all 
possible memory insn constraints, take intersection of basic and index 
reg classes for the constraints and use them instead of the default base 
and reg classes.

The required functionality is absent in reload too.

I would say that it is a moderate size project (1-2 months for me).  It 
still requires to introduce new hooks and I guess there are few cases 
when we will still assign hard regs out of desirable base class for 
address pseudos and this will results in generation of additional reload 
insns.  It also means much more additional changes in RA source code and 
x86 machine dependent files.

Probably, with this approach there will be also edge cases when we need 
to solve new PRs because of LRA failures to generate the correct code 
but I believe they can be solved.

Therefore I lean toward the current Intel approach when to get base reg 
class we pass the insn as a parameter additionally to memory mode.