[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #3 from Vladimir Makarov vmakarov at redhat dot com 2012-05-10 18:30:19 UTC --- I've tried a recent trunk on gcc63 of the compiler farm with -O0. The compilation takes about 300sec. I checked also gcc-4.3 (this last version with the old RA), it takes also about 300sec. The actual old RA is slower (it takes 150sec) than IRA (it takes 55sec) but register information pass (more exactly regstat_compute_ri which is a part of DF-infrastructure) takes more time in the trunk than in gcc4.3. So my times are different what you reported. Probably it depends on a machine (gcc63 is relatively modern SPARC machine with NIAGARA processors). After some investigation, I found that the trunk gcc calls regstat_compute_ri more than gcc-4.3. That is a result of recent addition to IRA to move some insns (a month old Bernd's patch). It is not worth to do for -O0. So I am going to switch it off and achieve the same number of regstat_compute_ri calls (2 of them) as in gcc-4.3 and that means achieving less 200sec of compilation time. (65% of previous time). I am going to submit a patch today. The futher improvement of regstat_compute_ri is not possible because we need one call for IRA needs and one call after reload transformations (for subsequent passes). Speedup of IRA itself can have only a small impact. I don't see how it is possible. It is very simple and fast enough (3 times faster than the old RA). One might think that not doing RA at all (setting -1 for all reg_renumber elements) could speed the case up. But this is not true. It increases reload work enormously and generates 2-3 times more insns which will slow down the compiler even more. So, Ian, if you need more speedup for -O0, regstat_compute_ri should be improved. But that is not my responsibility area. For me, it is strange that such simple task (which requires 1 pass of RTL) takes so much time for this case.
[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-05-10 CC||steven at gcc dot gnu.org AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1 --- Comment #4 from Steven Bosscher steven at gcc dot gnu.org 2012-05-10 18:37:11 UTC --- DF - mine to investigate.
[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org 2012-05-10 19:58:09 UTC --- Author: vmakarov Date: Thu May 10 19:58:01 2012 New Revision: 187373 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=187373 Log: 2012-05-10 Vladimir Makarov vmaka...@redhat.com PR rtl-optimization/53125 * ira.c (ira): Call find_moveable_pseudos or move_unallocated_pseudos if only ira_conflicts_p is true. Modified: trunk/gcc/ChangeLog trunk/gcc/ira.c
[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #6 from Steven Bosscher steven at gcc dot gnu.org 2012-05-10 22:17:36 UTC --- Created attachment 27369 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27369 Compute REG_LIVE_LENGTH smarter The way local_live is used to compute REG_LIVE_LENGTH is just stupid. Something like this patch would be helpful (drops from 73s after Vlad's patch to 39s). A complete version of this should also handle MW-hardregs.
[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #2 from Vladimir Makarov vmakarov at redhat dot com 2012-04-29 00:08:54 UTC --- I'll look at this PR in a week.
[Bug rtl-optimization/53125] Very slow register allocation on SPARC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53125 --- Comment #1 from Ian Lance Taylor ian at airs dot com 2012-04-25 22:34:17 UTC --- Out of curiousity I tried compiling the test case with -O2. On x86_64 it took 57.4 seconds, on SPARC it took 20 minutes 33 seconds.
