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?


Michael Matz <matz at suse dot de> writes:

> 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).

Again thanks for your answer.

My code must improve generated code quality and it's required for
constrained architectures.
Correction:
IE: We have a web to spill:

i2  use web1
...[1]
i3  use web1
...[2]
i4  use web1

Allocator generate spill insns:

i21 def web11 web1-pseudo-spill-slot
i2  use web11
...[1]
i31 def web12 web1-pseudo-spill-slot
i3  use web12
...[2]
i41 def web13 web1-pseudo-spill-slot
i4  use web13

After this stage we have an increased or decreased colorization
possibility. (Decreased if web1 before spill was overconstrained
ie. has CREG class on x86)

My code substitute web1-pseudo-spill-slot to real stack slot if and
only if colorization phase can't colorize web1-pseudo-spill-slot.
This pass similar to undo of previous spill phase combined with
substitution of web1-pseudo-spill-slot to web1-real-stack-slot.
After such substitution we will not have web1-pseudo-spill-slot,
web11, web12, web13.

i2  use web1-real-stack-slot
...
i3  use web1-real-stack-slot
...
i4  use web1-real-stack-slot

So, number of webs reduced (number of conflicts will be definitely
reduced) and possibility of graph colorization increased. I hope to
colorize full graph in next colorization phase.

I'm agree that this method increased a count of allocator passes, but
this method must improve code quality.

Denis.

PS: Especially for Daniel ! Look to ra-rewrite.c: actual_spill

-------------- fragment of ra-rewrite.c ----------------
actual_spill (spill_p)
     int spill_p ATTRIBUTE_UNUSED;
{
  int i;
  bitmap new_deaths;

  /* If we have a webs colored by an_unusable_color (ie we think that they are
     already in frame) we must put such webs to frame.  */
  if (/* !spill_p && */ subst_to_stack_p ())
#------^^^^^^^^^^^^^^^^  Just remove comments and you will have extra
#                        passes only at end of allocation process.
    /* If you uncomment the SPILL_P usage then you will have a calls to
       assign_stack_slots only at end of allocation process.
       See to the caller of actual_spill.  */
    {
-------------------------------------------------------

Daniel. Try to remove comments around `!spill_p &&' and compare generated code
quality for both cases (commented and not commented `!spill_p &&').


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