[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
-- What|Removed |Added Target Milestone|3.4.4 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
-- Bug 15242 depends on bug 20648, which changed state. Bug 20648 Summary: [4.0/4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648 What|Old Value |New Value Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
-- Bug 15242 depends on bug 20648, which changed state. Bug 20648 Summary: [4.0 regression] ICE in cfg_layout_redirect_edge_and_branch_force http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648 What|Old Value |New Value Status|REOPENED|ASSIGNED Status|ASSIGNED|NEW Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
-- Bug 15242 depends on bug 20648, which changed state. Bug 20648 Summary: [4.0/4.1 regression] ICE in cfg_layout_redirect_edge_and_branch_force http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20648 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|WAITING Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From anton at mips dot complang dot tuwien dot ac dot at 2005-03-12 21:38 --- Subject: Re: [3.3/3.4 regression] pessimization of goto * steven at gcc dot gnu dot org wrote: --- Additional Comments From steven at gcc dot gnu dot org 2005-03-10 12:48 --- Maybe there should be another combining pass after the duplication of the indirect jumps. Should I create another PR for this? There should not be another combining pass (you really mean constant propagation). I meant Instruction combination (`combine.c'). Not sure if this is replaced by something else in the recent gccs. Why do you think I mean constant propagation? This new unfactoring stuff runs after register allocation, so such a pass would not really help, except maybe to make the code look prettier to you. Ouch. No way to fix that? That's the cost we wanted to avoid. But, is this: mov0xfffc(%ebx),%eax jmp*%eax slower than this: jmp*0xfffc(%ebx) or have you not tried that (e.g. by hacking the assembly by hand)? Ok, I hacked the assembly by hand, and this is what I got: All numbers are user times in seconds for gforth-fast-0.6.2: Pentium-4 2.26 GHz (i386 code): no-dynamic no-super dynamic combined? yes no yes noyes no siev 0.47 0.49 0.36 0.36 0.33 0.33 bubble 0.81 0.81 0.52 0.53 0.47 0.47 matrix 1.03 1.01 0.30 0.30 0.36 0.35 fib0.70 0.68 0.75 0.60 0.53 0.58 Opteron 2GHz (i386 code): no-dynamic no-super dynamic combined? yes no yes noyes no siev 0.46 0.47 0.37 0.36 0.33 0.32 bubble 0.73 0.74 0.50 0.51 0.50 0.51 matrix 0.93 0.95 0.35 0.34 0.31 0.32 fib0.63 0.64 0.49 0.50 0.44 0.45 No-super performs the same number of indirect branches (and anything else) as no-dynamic, but has better branch prediction. Dynamic is like no-super, but eliminates many of the indirect branches. So, overall the instruction combination alone does not make much of a difference on these CPUs. - anton -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From stevenb at suse dot de 2005-03-12 21:54 --- Subject: Re: [3.3/3.4 regression] pessimization of goto * Combine runs before register allocation. You cannot run it after register allocation. I don't think you can run it twice, even. And no, after register allocation you are not magically going to win back that register. Tough luck. Given your numbers, replacing the reg with its known value might still be a win. But I'm not going to do it ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From steven at gcc dot gnu dot org 2005-03-10 12:48 --- Maybe there should be another combining pass after the duplication of the indirect jumps. Should I create another PR for this? There should not be another combining pass (you really mean constant propagation). This new unfactoring stuff runs after register allocation, so such a pass would not really help, except maybe to make the code look prettier to you. But, is this: mov0xfffc(%ebx),%eax jmp*%eax slower than this: jmp*0xfffc(%ebx) or have you not tried that (e.g. by hacking the assembly by hand)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From anton at mips dot complang dot tuwien dot ac dot at 2005-02-27 10:47 --- Subject: Re: [3.3/3.4/4.0 regression] pessimization of goto * steven at gcc dot gnu dot org wrote: Updated patch for this problem Ok, I have now tried it with gcc-4.0-20050220 and gforth-0.6.2 on i386 and it works ok. There is a minor remaining regression related to this issue: gcc-4.0 compiles goto **(ip-1); into 0x804b50d engine+1341:mov0xfffc(%ebx),%eax 0x804b510 engine+1344:jmp*%eax gcc-2.95 compiles it into 0x804b103 engine+227: jmp*0xfffc(%ebx) which looks better. Maybe there should be another combining pass after the duplication of the indirect jumps. Should I create another PR for this? Here are updated timing results (gforth-0.6.2 configured with --enable-force-reg): Pentium 4 2.26GHz; numbers are times in seconds user time gcc-4.0-20050220 gcc-2.95.3 gcc-3.3 gcc-3.4.0 default no-reorder-blocks dynamic no-dyn dynamic no-dyn no-dyndynamic dynamic siev0.240.480.310.470.50 0.370.28 bubble 0.300.780.360.770.78 0.400.36 matrix 0.190.940.170.920.96 0.180.18 fib 0.340.570.410.580.59 0.430.40 - anton -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From kazu at cs dot umass dot edu 2005-02-07 05:28 --- Is this PR fixed? If so, please close it. -- What|Removed |Added CC||stevenb at suse dot de Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-02-07 05:32 --- (In reply to comment #28) Is this PR fixed? If so, please close it. it is fixed on the mainline but still not fixed on the 3.4 branch as this is a regression we should keep it open until The RM says otherwise. -- What|Removed |Added Status|WAITING |NEW Last reconfirmed|2004-12-20 01:17:59 |2005-02-07 05:32:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
[Bug rtl-optimization/15242] [3.3/3.4 regression] pessimization of goto *
--- Additional Comments From steven at gcc dot gnu dot org 2005-02-01 10:11 --- Should be fixed on mainline now. -- What|Removed |Added AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[3.3/3.4/4.0 regression]|[3.3/3.4 regression] |pessimization of goto * |pessimization of goto * http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15242
