[Bug target/36539] New: [4.4 regression] IRA doesn't allocate asm output being returned to eax

[Bug target/36539] New: [4.4 regression] IRA doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

Using today's IRA branch (r136683), on the attached file.

> gcc -O3 -fno-pic -fomit-frame-pointer -m64 -S cabac-ret.i -fira
_get_cabac:
LFB2:
        pushq   %rbx
LCFI0:
        movl    (%rdi), %eax
        movl    4(%rdi), %r8d
# 16 "cabac-ret.i" 1
        #%ebx %r8d %ax 24(%rdi) %rsi
# 0 "" 2
        movl    %eax, (%rdi)
        movl    %r8d, 4(%rdi)
        movl    %ebx, %eax
        popq    %rbx
        andl    $1, %eax
        ret

with an unnecessary mov %ebx, %eax. Without -fira:
        movl    (%rdi), %r8d
        movl    4(%rdi), %r9d
# 16 "cabac-ret.i" 1
        #%eax %r9d %r8w 24(%rdi) %rsi
# 0 "" 2
        movl    %r8d, (%rdi)
        movl    %r9d, 4(%rdi)
        andl    $1, %eax
        ret

Both allocators don't allocate bit to eax in 32-bit mode, though all other
compilers with inline asm support I tried did. gcc 3.3 does, as well, but no
other version seemed to.

In this case it's not a problem, since changing the class to "=&a" fixes it,
but the function will be inlined a lot and I don't want to put unnecessary
constraints on it.


-- 
           Summary: [4.4 regression] IRA doesn't allocate asm output being
                    returned to eax
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: astrange at ithinksw dot com
GCC target triplet: x86_64-*-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

------- Comment #1 from astrange at ithinksw dot com  2008-06-14 06:48 -------
Created an attachment (id=15771)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15771&action=view)
testcase


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] IRA doesn't allocate asm output being returned to eax

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2008-06-14 06:52 -------
IRA has not been committed to the trunk yet so it is not a regression (yet).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|RA doesn't allocate asm     |IRA doesn't allocate asm
                   |output being returned to eax|output being returned to eax


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

------- Comment #3 from astrange at ithinksw dot com  2008-08-27 04:41 -------
Now it is.


-- 

astrange at ithinksw dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|IRA doesn't allocate asm    |[4.4 regression] IRA doesn't
                   |output being returned to eax|allocate asm output being
                   |                            |returned to eax


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
   Target Milestone|---                         |4.4.0


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

[vmakarov at redhat dot com]

------- Comment #4 from vmakarov at redhat dot com  2008-08-29 19:17 -------
I believe that patch

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg02279.html

solves the problem.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] [4.4 regression] IRA doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

------- Comment #5 from astrange at ithinksw dot com  2008-09-04 04:02 -------
It is fixed for me on x86-64. For i386 it's still suboptimal:
_get_cabac:
        subl    $28, %esp
        movl    %esi, 16(%esp)
        movl    %edi, 20(%esp)
        movl    %ebx, 12(%esp)
        movl    %ebp, 24(%esp)
        movl    32(%esp), %esi
        movl    36(%esp), %edi
        movl    (%esi), %eax
        movl    4(%esi), %ebx
# 16 "../cabac-ret.i" 1
        #%ebp %ebx %ax 16(%esi) %edi
# 0 "" 2
        movl    %eax, (%esi)
        movl    %ebx, 4(%esi)
        movl    %ebp, %eax
        movl    12(%esp), %ebx
        andl    $1, %eax
        movl    16(%esp), %esi
        movl    20(%esp), %edi
        movl    24(%esp), %ebp
        addl    $28, %esp
        ret

but not a regression (code is worse without IRA).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] IRA doesn't allocate asm output being returned to eax

[jsm28 at gcc dot gnu dot org]

------- Comment #6 from jsm28 at gcc dot gnu dot org  2008-09-09 20:14 -------
Removing regression marker given the last comment.


-- 

jsm28 at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.4 regression] IRA doesn't|IRA doesn't allocate asm
                   |allocate asm output being   |output being returned to eax
                   |returned to eax             |
   Target Milestone|4.4.0                       |---


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] IRA+i386 doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

------- Comment #7 from astrange at ithinksw dot com  2008-09-18 01:29 -------
Updated to 32-bit only.


-- 

astrange at ithinksw dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
 GCC target triplet|x86_64-*-*                  |i?86-*-*
            Summary|IRA doesn't allocate asm    |IRA+i386 doesn't allocate
                   |output being returned to eax|asm output being returned to
                   |                            |eax


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] IRA+i386 doesn't allocate asm output being returned to eax

[astrange at ithinksw dot com]

------- Comment #8 from astrange at ithinksw dot com  2008-12-05 20:08 -------
With some recent changes IRA makes better decisions now but they don't survive
reload.

Using
> /gcc -O3 -fomit-frame-pointer -fno-pic -fdump-rtl-ira -S cabac-ret.i

I get about the same asm and this in the IRA dump:
**** Allocnos coloring:


  Loop 0 (parent -1, header bb0, depth 0)
    bbs: 2
    all: 0r64 1r58 2r62 3r59 4r60 5r63
    modified regnos: 58 59 60 62 63 64
    border:
    Pressure: GENERAL_REGS=6
    Reg 58 of GENERAL_REGS has 2 regs less
    Reg 62 of GENERAL_REGS has 2 regs less
    Reg 59 of GENERAL_REGS has 2 regs less
    Reg 60 of GENERAL_REGS has 2 regs less
    Reg 63 of GENERAL_REGS has 2 regs less
      Pushing a0(r64,l0)
      Pushing a3(r59,l0)(potential spill: pri=2857, cost=20000)
      Pushing a1(r58,l0)
      Pushing a5(r63,l0)
      Pushing a2(r62,l0)
      Pushing a4(r60,l0)
      Popping a4(r60,l0)  -- assign reg 3
      Popping a2(r62,l0)  -- assign reg 4
      Popping a5(r63,l0)  -- assign reg 0 <- "r"(state)
      Popping a1(r58,l0)  -- assign reg 0 <- "=&r"(bit)
      Popping a3(r59,l0)  -- assign reg 5
      Popping a0(r64,l0)  -- assign reg 0 <- returned bit&1

a1 and a5 should be conflicting, since a1 is an earlyclobber output and can't
share a register with any of the inputs. reload fixes this by moving it to a
worse register. 


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] IRA doesn't account for earlyclobber asm conflicts

[law at redhat dot com]

------- Comment #9 from law at redhat dot com  2010-01-29 11:01 -------
At some point IRA's handling of earlyclobber constraints improved enough to get
the conflicts right in this PR.  Unfortunately, that is not sufficient to
generate good code.  

If we compile the testcase on i686-pc-linux-gnu with -O2 -fomit-frame-pointer,
we should be able to allocate hard regs for all the allocnos *and* do so
without generating any reloads.  Unfortunately, IRA makes poor register
selections which ultimately lead to reloading.

Pass 0 for finding pseudo/allocno costs

    a0 (r68,l0) best AREG, cover GENERAL_REGS
    a4 (r67,l0) best Q_REGS, cover GENERAL_REGS
    a3 (r66,l0) best GENERAL_REGS, cover GENERAL_REGS
    a1 (r65,l0) best GENERAL_REGS, cover GENERAL_REGS
    a5 (r64,l0) best GENERAL_REGS, cover GENERAL_REGS
    a2 (r63,l0) best GENERAL_REGS, cover GENERAL_REGS
    a7 (r59,l0) best GENERAL_REGS, cover GENERAL_REGS
    a6 (r58,l0) best GENERAL_REGS, cover GENERAL_REGS

  a0(r68,l0) costs: AREG:-1000,-1000 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0
DIREG:0,0 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0
GENERAL_REGS:0,0 MEM:6000
  a1(r65,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:7000
  a2(r63,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:28000
  a3(r66,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:16000
  a4(r67,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:4000,4000
DIREG:4000,4000 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:4000,4000
GENERAL_REGS:4000,4000 MEM:16000
  a5(r64,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:4000
  a6(r58,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000
  a7(r59,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000


Pass 1 for finding pseudo/allocno costs

    r68: preferred AREG, alternative GENERAL_REGS, cover GENERAL_REGS
    r67: preferred Q_REGS, alternative GENERAL_REGS, cover GENERAL_REGS
    r66: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
    r65: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
    r64: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
    r63: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
    r59: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS
    r58: preferred GENERAL_REGS, alternative NO_REGS, cover GENERAL_REGS

  a0(r68,l0) costs: AREG:-1000,-1000 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0
DIREG:0,0 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0
GENERAL_REGS:0,0 MEM:6000
  a1(r65,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:7000
  a2(r63,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:28000
  a3(r66,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:16000
  a4(r67,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:4000,4000
DIREG:4000,4000 AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:4000,4000
GENERAL_REGS:4000,4000 MEM:16000
  a5(r64,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:4000
  a6(r58,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000
  a7(r59,l0) costs: AREG:0,0 DREG:0,0 CREG:0,0 BREG:0,0 SIREG:0,0 DIREG:0,0
AD_REGS:0,0 CLOBBERED_REGS:0,0 Q_REGS:0,0 NON_Q_REGS:0,0 GENERAL_REGS:0,0
MEM:3000

That looks fairly reasonable.  pseudo 68 is the return value, so assigning it
into ax is a win.  r67 wants Q_REGS so assigning it to SI, DI, or NON_Q has a
cost.


;; a0(r68,l0) conflicts:
;;     total conflict hard regs:
;;     conflict hard regs:
;; a1(r65,l0) conflicts: a3(r66,l0) a2(r63,l0) a4(r67,l0) a5(r64,l0)
;;     total conflict hard regs: 1 2
;;     conflict hard regs: 1 2
;; a2(r63,l0) conflicts: a1(r65,l0) a3(r66,l0) a4(r67,l0) a5(r64,l0) a6(r58,l0)
a7(r59,l0)
;;     total conflict hard regs: 1 2
;;     conflict hard regs: 1 2
;; a3(r66,l0) conflicts: a1(r65,l0) a2(r63,l0) a4(r67,l0) a5(r64,l0) a6(r58,l0)
;;     total conflict hard regs: 1 2
;;     conflict hard regs: 1 2
;; a4(r67,l0) conflicts: a1(r65,l0) a3(r66,l0) a2(r63,l0) a5(r64,l0)
;;     total conflict hard regs: 1 2
;;     conflict hard regs: 1 2
;; a5(r64,l0) conflicts: a1(r65,l0) a3(r66,l0) a2(r63,l0) a4(r67,l0)
;;     total conflict hard regs: 1 2
;;     conflict hard regs: 1 2
;; a6(r58,l0) conflicts: a3(r66,l0) a2(r63,l0) a7(r59,l0)
;;     total conflict hard regs:
;;     conflict hard regs:
;; a7(r59,l0) conflicts: a2(r63,l0) a6(r58,l0)
;;     total conflict hard regs:
;;     conflict hard regs:

  cp0:a3(r66)<->a7(r59)@1000:move
  cp1:a4(r67)<->a6(r58)@1000:move
  cp2:a0(r68)<->a1(r65)@125:shuffle


The r65/r68 copy will cause IRA to want to use ax for r65 and as a result will
increase the cost of ax for every pseudo which conflicts with r65 (r63, r64,
r66, r67).

So far, so good.  The problem is I don't see where we increase the cost of
Q_REGS for pseudos which conflict with r67.  So when we color:



      Pushing a7(r59,l0)
      Pushing a6(r58,l0)
      Pushing a0(r68,l0)
      Pushing a3(r66,l0)(potential spill: pri=2285, cost=16000)
      Pushing a4(r67,l0)(potential spill: pri=2666, cost=16000)
      Pushing a1(r65,l0)
      Pushing a5(r64,l0)
      Pushing a2(r63,l0)
      Popping a2(r63,l0)  -- assign reg 3
      Popping a5(r64,l0)  -- assign reg 4
      Popping a1(r65,l0)  -- assign reg 0
      Popping a4(r67,l0)  -- assign reg 5
      Popping a3(r66,l0)  -- assign reg 6
      Popping a0(r68,l0)  -- assign reg 0
      Popping a6(r58,l0)  -- assign reg 5
      Popping a7(r59,l0)  -- assign reg 6

We've assigned r63 into bx and thus r67 can't be assigned into bx.  We
ultimately assign r67 into di.  That in turn causes r65 to get spilled during
reload so that r67 can be reloaded into a  Q_REGs and ultimately we generate
crappy code.

It seems to me we ought to have code which increases the cost for Q_REGS for
pseudos conflicting with r67, but I can't seem to find it.  FWIW, if I manually
increase the cost of Q_REGS for pseudos r63, r64, r65, r66) I get the following
coloring:

      Pushing a7(r59,l0)
      Pushing a6(r58,l0)
      Pushing a0(r68,l0)
      Pushing a3(r66,l0)(potential spill: pri=2285, cost=16000)
      Pushing a4(r67,l0)(potential spill: pri=2666, cost=16000)
      Pushing a1(r65,l0)
      Pushing a5(r64,l0)
      Pushing a2(r63,l0)
      Popping a2(r63,l0)  -- assign reg 4
      Popping a5(r64,l0)  -- assign reg 5
      Popping a1(r65,l0)  -- assign reg 0
      Popping a4(r67,l0)  -- assign reg 3
      Popping a3(r66,l0)  -- assign reg 6
      Popping a0(r68,l0)  -- assign reg 0
      Popping a6(r58,l0)  -- assign reg 3
      Popping a7(r59,l0)  -- assign reg 6

Which is a perfect allocation requiring no reloads.  


-- 

law at redhat dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-01-29 11:01:15
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539

[Bug target/36539] Poor register allocation from IRA

[vmakarov at redhat dot com]

------- Comment #10 from vmakarov at redhat dot com  2010-01-29 20:33 -------
Jeff, I saw analogous problem when I worked on improving IRA performance.  I
checked the approach you are proposing.  But it works considerably worse on
SPEC2000.  Finally, I found that the best conflicting cost technique works when
we change it only for one hard register when pseudo best cost is achieved on
one hard register, e.g. best cost is achieved on register class containing one
hard register or assigning particular hard register removes a copy.

Why technique you are proposing does not work well in average for classes (like
Q_REGS in this case) containing more one register? This is just my speculation.
 If # conflicting pseudos is less size of QREGS we should not modify conflict
costs of the pseudo for QREGS because QREGS for the conflicting pseudos can be
more profitable and we still will assign QREG for the pseudo.  Even if #
conflicting pseudos > size of QREGS, they still might be assigned to hard
registers which are only part of QREGS.  It is hard to predict.

I am not saying that we should not work on this problem. I think we should try
more sophisticated heuristics.  Although I don't know what one (it could be
conflict cost modifications only when register pressure for QREGS is high
during pseudo live range but such heuristic will take some time to implement
and i am not still sure that it will work better in average).

Unfortunately, there will be cases when RA could work better because RA
algorithms are heuristic ones.  What we should focus on is to improve
performance for credible benchmarks like SPEC2000/SPEC2006.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36539