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, February 27, 2003, at 11:39 AM, Christian Ehrhardt wrote:


On Tue, Feb 25, 2003 at 05:57:15PM +0100, Michael Matz wrote:
this is merge_moves from ra-colorize.c which has somewhat broken list
handling IMHO.

Hmm, I must have been half asleep, when I wrote that. Although note, that
with the default setting of flags noone will notice that error, as
web->moves is empty with optimistic coalescing. I'll commit the below
patch, once bootstrapping/regtesting on i686-linux is done (regalloc
branch and HEAD). I'm unclear if I need permission for 3.3.

Thanks for the patch. Another mostly unrelated issue: The behaviour of the register allocator with the following testcase (and others) is IMHO suboptimal:

extern void byte_store_op2 (int op, unsigned char *loc, int arg1, int arg2);
static void
byte_insert_op2 (op, loc, arg1, arg2, end)
int op;
unsigned char *loc;
int arg1, arg2;
unsigned char *end;
{
register unsigned char *pfrom = end;
register unsigned char *pto = end + 1 + 2 * 2;
while (pfrom != loc)
*--pto = *--pfrom;
byte_store_op2 (op, loc, arg1, arg2);
}


With -O2 this testcase gives 7 non-precolored webs that all conflict with
each other, i.e. the conflict graph is a complete graph with 7 nodes.
With the current code it takes no less than 8 passes to get this graph
colored. The problem is that the allocator allows coalescing between
spill slots and non spill slots.

new-regalloc-branch isn't very good compile-time wise.
For instance, we can't ever color in one pass anymore (it pretends something has changed, even if nothing has, so the minimum number of passes is 2).


x86 is also just not an easy architecture to color for.

I'm actively working on merging good parts to the head that don't increase compile time (but increase runtime performance), as well as modularizing the new-register allocator so that different architectures can do different things easily, for speed.

I've SPEC benchmarked every change[1] i'm moving from new-regalloc in order to make sure it improves performance

Thus, if you are concerned with improving compile time, you might want to just try to speed up things algorithmically, rather than small pieces at a time, since i can take care of that.
--Dan
[1] actually, i spec'd every combination of every change i'm moving, to make sure they don't interact badly. But only on the two spec tests that were most affected by bad choices in register allocation/spilling. Otherwise, it would have taken days or weeks to do this.



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