[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2014-01-01 Thread steven at gcc dot gnu.org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171 Steven Bosscher steven at gcc dot gnu.org changed: What|Removed |Added CC||steven at gcc

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-10-30 Thread sje at cup dot hp dot com
--- Comment #7 from sje at cup dot hp dot com 2009-10-30 21:00 --- Has a patch to move update_equiv_regs into its own pass been submitted? I don't see one and IA64 is still producing the 'wrong' scheduling. -- sje at cup dot hp dot com changed: What|Removed

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-10-30 Thread vmakarov at redhat dot com
--- Comment #8 from vmakarov at redhat dot com 2009-10-30 21:57 --- Unfortunately, not yet because I had some failures after applying the patch. I postponed work on this but now I have time to continue the work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-09-02 Thread bergner at gcc dot gnu dot org
--- Comment #6 from bergner at gcc dot gnu dot org 2009-09-02 21:47 --- My patch solved the problem, but was very very neutral wrt SPEC2000 scores. Vlad's idea of moving update_equiv_regs() into its own pass before sched1 makes sense to me and seems to produce better performing code

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-08-26 Thread bergner at gcc dot gnu dot org
--- Comment #2 from bergner at gcc dot gnu dot org 2009-08-26 13:44 --- The problem here, is that for some reason, IRA is spilling the two pseudos in the test case, even though it seems it should be trivial. Looking deeper. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-08-26 Thread bergner at gcc dot gnu dot org
--- Comment #3 from bergner at gcc dot gnu dot org 2009-08-26 15:14 --- Actually, they're already reordered by the time we call ira_color and the ira dumps shows that: ;; Function f (f) starting the processing of deferred insns ending the processing of deferred insns df_analyze called

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-08-26 Thread bergner at gcc dot gnu dot org
--- Comment #4 from bergner at gcc dot gnu dot org 2009-08-26 15:22 --- It's update_equiv_regs() that is causing this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41171

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-08-26 Thread bergner at gcc dot gnu dot org
--- Comment #5 from bergner at gcc dot gnu dot org 2009-08-26 20:57 --- From my bug analysis and request for comment on the mailinglist: http://gcc.gnu.org/ml/gcc/2009-08/msg00485.html This is caused by update_equiv_regs() which IRA inherited from local-alloc.c. Although with gcc

[Bug rtl-optimization/41171] register allocator undoing optimal schedule

2009-08-25 Thread nemet at gcc dot gnu dot org
--- Comment #1 from nemet at gcc dot gnu dot org 2009-08-25 23:05 --- It's also a regression if the load-immediates can dual issue. I.e. see below how the code gets worse between sched1 and sched2 on octeon. I am cc'ing Vlad in case he has some ideas. ;;