[Bug target/36539] Poor register allocation from IRA

[Bug target/36539] Poor register allocation from IRA

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
GCC 4.8+ for -m32 -O2 -fno-pic -fomit-frame-pointer:
get_cabac:
        pushl   %ebp
        pushl   %edi
        pushl   %esi
        pushl   %ebx
        movl    20(%esp), %esi
        movl    24(%esp), %ebp
        movl    4(%esi), %ebx
        movl    (%esi), %eax
#APP
# 16 "/app/example.cpp" 1
        #%edi %ebx %ax 16(%esi) %ebp
# 0 "" 2
#NO_APP
        movl    %eax, (%esi)
        movl    %edi, %eax
        movl    %ebx, 4(%esi)
        andl    $1, %eax
        popl    %ebx
        popl    %esi
        popl    %edi
        popl    %ebp
        ret

Which most likely means it was fixed when LRA came in, aka
r0-119686-g55a2c3226a3e90 so closing as fixed for GCC 4.8.

[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