[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>]

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.