https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115673

Peter Bergner <bergner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |vmakarov at gcc dot gnu.org

--- Comment #13 from Peter Bergner <bergner at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #12)
> Re-confirmed.
> +FAIL: gcc.target/i386/pr91384.c scan-assembler-not testl

int
test (int a)
{
  int r;

  if (r = -a)
    foo ();
  else
    bar ();

  return r;
}

Looking at just this test case, the first (x86_64) RTL difference between trunk
and trunk with Surya's patch reverted, I see:

     Hard reg set forest:
       0:( 0-6 8-15 20-51)@0
         1:( 0-6 36-43)@36000
           2:( 0 3 6 40-43)@18000
       Allocno a0r98 of GENERAL_REGS(15) has 7 avail. regs  0 3 6 40-43, node: 
0 3 6 40-43 (confl regs =  7-35 44-91)
       Allocno a1r101 of GENERAL_REGS(15) has 15 avail. regs  0-6 36-43, node: 
0-6 36-43 (confl regs =  7-35 44-91)
       Forming thread from colorable bucket:
       Pushing a0(r98,l0)(cost 0)
       Pushing a1(r101,l0)(cost 0)
       Popping a1(r101,l0)  --         assign reg 5
-      Popping a0(r98,l0)  --         assign reg 0
+      Popping a0(r98,l0)  --         assign reg 3
 Disposition:
-    0:r98  l0     0    1:r101 l0     5
+    0:r98  l0     3    1:r101 l0     5
 New iteration of spill/restore move
-+++Costs: overall 14000, reg 14000, mem 0, ld 0, st 0, move 0
++++Costs: overall 5000, reg 5000, mem 0, ld 0, st 0, move 0
 +++       move loops 0, new jumps 0

So with Surya's patch, we assign hardreg 0 (%rax and volatile) to variable "r"
versus hardreg 3 (%rbx and non-volatile).  I think the increase of the
allocation cost of using the non-volatile hardreg 3 by Surya's patch is
justified.  However, I'm wondering whether we should also be increasing the
allocation cost of using a volatile hardreg for pseudos that are live across
calls, since those too will need to be saved/restored.

Reply via email to