On 9/7/23 02:23, Uros Bizjak wrote:
On Wed, Sep 6, 2023 at 9:43 PM Vladimir Makarov <vmaka...@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.
