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?


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.  Ergo
there's no conflict between webs and the stack pointer.  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 different on more constrained machines, where the offset has to be
loaded into an index register.  I'm not sure, how the code will currently
look like for those, but I suppose the offset will be loaded before each
reference.  So this one also can be colored differently for each ref, like
if there were stack pseudos instead of real mem slots.

The problem with stack pseudos on constrained machines is, that the
actual mem references to the stack slots they represent are only created
after coloring.  This means, that all those mems need to be already
non-conflicting with all the other webs used around them.  On
non-constrained machines that's trivial, simply using the fixed stack
pointer.  But on other machines creating such mems involves using index
registers, and this would destroy the coloring, which is, why Denis made
them created during the coloring process, so they are taken into account.
I.e. on some machines this is useless (and arguably leads to more
difficult coloring), but on others it's needed for correctness (Denis,
correct me if I'm wrong here).


Ciao,
Michael.


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