[Bug rtl-optimization/65862] [MIPS] IRA/LRA issue: integers spilled to floating-point registers
vmakarov at gcc dot gnu.org
gcc-bugzilla@gcc.gnu.org
Mon Apr 27 16:17:00 GMT 2015
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65862
Vladimir Makarov <vmakarov at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vmakarov at gcc dot gnu.org
--- Comment #3 from Vladimir Makarov <vmakarov at gcc dot gnu.org> ---
The result of the old patch which makes ALL_REGS available changes
the order of coloring and, as a consequence, the result of allocation for r218
and r220 after IRA. That is unfortunate result of heuristics approaches.
Before the patch:
...
Popping a4(r218,l0) -- assign reg 30
Popping a0(r220,l0) -- spill
...
Disposition:
... 4:r218 l0 30 6:r219 l0 16 0:r220 l0 mem
After patch:
Popping a0(r220,l0) -- assign reg 30
Popping a4(r218,l0) -- (memory is more profitable 184 vs 191) spill!
...
Disposition:
... 4:r218 l0 mem 6:r219 l0 16 0:r220 l0 30
The costs of MEM and FP_REGS are the same as for example r218 occurs in 2
insns:
59: r218:SI=r194:SI<=0x1
16: pc={(r218:SI!=0)?L18:pc}
The costs are equal if cost of moving general regs to/from fp regs or
memory are equal. So it looks ok to me.
r218 spilled in IRA is reassigned to a fp reg in *LRA*. It could be
changed if we used only preferred class in LRA for this. In this
case, r218 stays spilled and we remove one insn (saving the allocated
fp reg):
sdc1 $f20,64($sp)
I am not sure, that the result code is better as we access memory 3
times instead of access to $f20.
But I could try to use preferred class in LRA (after checking how it
affects x86/x86-64 performance), if such solution is ok for you.
But I can not just revert the patch making ALL_REGS available to make
coloring heuristic more fotunate for your particular case, as it
reopens the old PR for which the patch was created and i have no other
solutions for the old PR.
Robert, please let me know what do you think.
More information about the Gcc-bugs
mailing list