This is the mail archive of the gcc-patches@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 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.

 Ergo
there's no conflict between webs and the stack pointer.

Of course there is, since they can't use that register as a color now, and could before (since the pseudo spill slots could get different colors).


Even if it were a
candidate the webs would most probably already have conflicted with it, so
it doesn't really change the conflicts for the webs.


This is pure conjecture, i have stats that say otherwise (that they didn't conflict with it before, and do now).

Theory is nice, but the fact that it takes 15 passes to color something that used to take 3, the only difference is stack slots, and the number of conflicts on the newly spilled webs has gone up, tells me you are wrong.

All of this is academic anyway, since my solution is to not even consider merging the stack slot code until it doesn't cause 15 passes of coloring, *whatever* the reason.
Not that this stops you or anyone else, of course.


--Dan


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