https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95674
rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rsandifo at gcc dot gnu.org
--- Comment #4 from rsandifo at gcc dot gnu.org <rsandifo at gcc dot gnu.org>
---
(In reply to Vladimir Makarov from comment #3)
> I looked at this problem.
>
> All assignments are done in IRA (LRA does not change them). We can not make
> a better assignment because scratches do not permit to store any preferences
> from instruction constraints (pseudo-registers permits to do this). So
> storing and getting this info for scratches is the first step to solving the
> problem.
>
> LRA changes scratches to pseudo-registers to generate the correct code
> satisfying the insn constraints and turn them back to scratches when the
> corresponding pseudo-registers do not get hard registers. Moving change of
> scratches to pseudo-regs from LRA to IRA could help but it is a big work.
Yeah, sounds useful! Could it be done as a prepass before IRA proper?
(Maybe not -- haven't really thought about it much.)
> Another solution is to not use scratches in machine-descriptions and use
> pseudo-registers instead. Scratches are bad and should be avoided as much
> as possible. I expressed this several times. Besides it is not possible to
> keep hard register preferences for them, they also can not be taken into
> account in conflict graph and this results in overoptimistic assignments
> which LRA has to correct.
I can see that scratches make life harder for the register allocators,
at least until the above change is made. But they're very useful for
pre-RA passes. They make it possible for any pass to use recog to match
a candidate instruction and have recog automatically add the required
scratches, without the passes having to cope with new registers being
created “spontaneously”. (Combine is of course the main example,
but others like fwprop benefit too.)
Although it would be possible to use pseudos instead, I'm not sure
the end result would be better than what we have now:
- Each pass would need to cope with recog creating new registers
- We'd need some way of deferring the creation of pseudo registers
for successful but speculative recogs that might later be rejected
for cost reasons, or at least have some kind of recycling scheme.
- Even then, we'll have more pseudos before RA, and so most of the
DF datastructures will be larger and perhaps sparser.
