On 4/19/23 14:53, Surya Kumari Jangala wrote:
...
I have a few queries:
1. A zero cost seems strange for the regs r14-r31. If using a reg in the
set [14..31] has zero cost, then why wasn’t such a reg chosen for r118
in the first place, instead of r3?
I guess it is because assign_hard_reg (see also calculate_saved_nregs)
takes into account that r31 not used yet needs insns to save/restore it
in prolog/epilog when we assign r31 the first time to any pseudos. All
pseudos assigned to r31 after that will not be punished. It is not
reflected in the hard reg costs as we do not know will be this hard
register assigned. Also an order of hard register assignment can be
used for some targets. It works when all assignment costs are the same.
2. In step 3, shouldn’t we restrict the register chosen to be a register
that has been assigned to a conflicting allocno? This is not the case for
the failing test. The allocno for r118 is assigned r31, but there is no
conflicting allocno that has been assigned r31.
Yes in this case, this approach could be used. But what if after
spilling conflicting pseudos for one pseudo, we can simply use hard
registers of the pseudos spilled before for free for another pseudo
conflicting with the spilled pseudos. So I think we should constrain to
any hard regs used before improve_allocation, whether they are used by
conflicting pseudos or not.
3. In steps 1 & 2, shouldn’t we consider the register save and restore
cost too? ’r31’ being a callee-save (non-volatile) register has to be
saved before being used, whereas this is not required for r3 which is a
caller-save (volatile) register.
I guess we could. I am not against improving the code. Especially as
IRA was developed for many years. For example cost calculations in
assign_hard_reg were improved before and after adding improve_allocation
and it might make some parts of code are less important. But any new
change would be nice to be proved by benchmarking (SPEC rates or size or
executed spilled insns etc). When improve_allocation was added, it
improved SPEC2000 for x86 but I don't remember by what margin.
Thank you for reporting this case and your questions, proposals and
interest in RA. I am open to review your patches for RA.
