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?


Hi,

On Thu, 27 Feb 2003, Christian Ehrhardt wrote:

> Thanks for the patch. Another mostly unrelated issue:
> The behaviour of the register allocator with the following testcase
> (and others) is IMHO suboptimal:
>
> [... description of problem, that ra coalesces spill pseudos and
>      non-spill pseudos ...]

Yes, a known problem.  On the current ra-branch this type of coalescing is
switched off (in a brutal way, i.e. those insns are not recognized as copy
insns anymore, which is a bit too pessimistic, only switching of actually
coalescing them is enough).

> This is a huge compile time performance problem. Adding the following
> test to aggressive coalesce reduced compile time dramatically (> 80%
> on my favourite test case, see below):
>
> Index: ra-colorize.c
> ===================================================================
> RCS file: /cvsroot/gcc/gcc/gcc/ra-colorize.c,v
> retrieving revision 1.1.2.8
> diff -u -r1.1.2.8 ra-colorize.c
> --- ra-colorize.c       1 Feb 2003 17:27:08 -0000       1.1.2.8
> +++ ra-colorize.c       27 Feb 2003 16:16:13 -0000
> @@ -2683,7 +2683,8 @@
>         if (s != t
>             && t->type != PRECOLORED
>             && !TEST_BIT (sup_igraph, s->id * num_webs + t->id)
> -           && !TEST_BIT (sup_igraph, t->id * num_webs + s->id))
> +           && !TEST_BIT (sup_igraph, t->id * num_webs + s->id)
> +           && (SPILL_SLOT_P (s->regno) == SPILL_SLOT_P (t->regno)))
>           {
>             if ((s->type == PRECOLORED && ok (t, s))
>                 || s->type != PRECOLORED)
>
> I realize that this patch may change the generated code. Do you
> have some kind of testsuite that can be used to measure the run
> time performance impact of this patch? For those (admittedly few)
> test cases that I looked in detail, the same code was generated with
> and without the patch.

No, when I'm really interested in quality of produced code I use SPEC
CPU2000, or look at some file where I noticed a problem.  But no specific
test-suite.

> Finally let me say a few words about my rational:

All points correct.  I guess, I will do something similar for the
new-regalloc-branch, and remove the non-detection of copy-insns involving
SPILL_SLOT_P's.


Ciao,
Michael.


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