This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bug in ra-colorize.c:merge_moves?



On Thursday, March 6, 2003, at 10:38 AM, Daniel Berlin wrote:



On Thursday, March 6, 2003, at 06:08 AM, Michael Matz wrote:


Hi,

On Wed, 5 Mar 2003, Daniel Berlin wrote:

Yes, but unless you've made symbol_refs of some new symbol to represent
the stack space you are using, they are still based off a register (in
this case, the stack register).

Which is fixed, and therefore not even a condidate for coloring.


But still causes conflicts, regardless, since the register is no longer available.


Sorry, read what you wrote wrong, since you said "candidate for coloring" rather than "register available to coloring", which is what you really meant.
And of course, this depends on the architecture.


Maybe you can explain why the number of conflicts *does* increase when Denis's code is used, since we ignore conflicts between fixed regs and pseudos.
Somethings is broken.


Testcases that show the number of passes has increased are easy to come by.
Just pick a file.


If you want one that shows particularly bad results, try expr.c.
Before, the number of functions taking at least 4 passes was 0 and it's now 7.
Before the spill slot coalescing change it was 49 on the new-regalloc-branch, which is um, bad.
Before:
[dberlin at dberlin gcc]$ grep "Pass 4" expr.i.25.lreg |uniq -c
[dberlin at dberlin gcc]$
After:
[dberlin at dberlin gcc]$ grep "Pass 4" expr.i.23.lreg |uniq -c
7 RegAlloc Pass 4



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]