This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bug in ra-colorize.c:merge_moves?
- From: Daniel Berlin <dberlin at dberlin dot org>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: Michael Matz <matz at suse dot de>,Denis Chertykov <denisc at overta dot ru>,Christian Ehrhardt <ehrhardt at mathematik dot uni-ulm dot de>, <gcc at gcc dot gnu dot org>, <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 6 Mar 2003 12:24:51 -0500
- Subject: 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