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: Denis Chertykov <denisc at overta dot ru>
- To: Michael Matz <matz at suse dot de>
- Cc: Daniel Berlin <dberlin at dberlin dot org>, 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: 06 Mar 2003 19:39:02 +0300
- Subject: Re: Bug in ra-colorize.c:merge_moves?
- References: <Pine.LNX.4.33.0303061154080.5124-100000@wotan.suse.de>
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 &&').