On 2004-04-17 I tried (as suggested some time earlier by Josef Zlomek) to move -frename-registers to -O1 level. Though the patch was successfully bootstrapped and regtested on i686-pc-linux-gnu, it caused a lot of bootstrapping failures on several targets, so Geoff keating approved another patch to remove -frename-registers from any -O level. At the same time, Richard Sandiford pointed out that -rename-registers takes up to 4% of compile-time, being quite a CPU hog. This PR tracks register renaming problems. Most likely it applies to earlier versions than 3.5 as well.
Looks like the buggy part is target bugginess and not -frename-register's fault at all. Confirmed based on the emails in the mailing lists.
ia64 and arm have been fixed. x86_64 has not, as far as I know, and regrename still remains a CPU hog.
This bug report is totally useless. There are no links to the relevant discussions that have apparently taken place. There are no test cases, no examples of what or where or why things go wrong. I believe this register renaming would be a useful pass for many targets, including amd64, so it would be nice to have this bug figured out and fixed. So if anyone knows where to find those discussions mentioned in comments #0 and #1, can he/she please link them to this report?
(In reply to comment #3) > if anyone knows where to find those discussions mentioned in comments > #0 and #1, can he/she please link them to this report? http://gcc.gnu.org/ml/gcc-patches/2004-04/msg00961.html
Thanks Serge!
The patch for PR18599 might have addressed the "slow" part of this bug report. The "buggy" part may also be fixed already -- a number of e500 related regrename.c patches went in since this bug report was opened, and it does look like those patches fixed real bugs, and maybe the same bugs as those referred to in this report.
I'd like to mention a known problem with -frename-registers. Quoting my analysis for another bug report: "However the underlying problem is still present and is now visible on x86-64: the register renaming pass (regrename.c) uses its own life analysis engine to compute the def-use chains. It turns out that it is less accurate than the all-purpose life analysis engine (flow.c) and, consequently, when the latter is invoked to update the global liveness info at the end of the pass, it may flag internal inconsistencies introduced because of the former. It is not immediately obvious what the best approach to solving that would be. A third life analysis engine exists (df.c) and is supposed to be modular, so we could try to plug it into regrename.c." The typical example is PR rtl-optimization/16586.
The liveness analysis in df.c misses the registers marked in flow.c:mark_regs_live_at_end, so that'd have to be fixed first.
Another bug in renaming just showed up on darwin rs6000. When renaming changes a register in the RTL, it does not make the corresponding change in attached FRAME_RELATED notes. This leads to inaccurate Dwarf exception tables and runtime failures in unwinding after a throw. Don't know how widespread this would be; other rs6000 targets for sure.
(In reply to comment #9) >Don't know how widespread this would be; other rs6000 targets for sure. Yes this shows up as PR 23392 with the GNU runtime and objc exceptions.
Still an issue here??
(In reply to comment #11) > Still an issue here?? I think the slowness still exist.
Haven't seen any reports of wrong-code coming out of register renaming in a while. Register renaming is enabled if loop unrolling / peeling is enabled. So the test coverage of this pass is much better than it used to be. I think that the wrong-code issue for this bug is fixed.
-frename-registers should be rewritten to use the new DF framework when dataflow branch is merged. Lowering priority to P3. This is not high priority.
Paolo, do you know what the status of this PR is? Ian said in comment #14 that the pass should be rewritten to use the DF framework. Has this happened? TIA.
No, but I don't think this should hold up marking this PR as fixed.
reopening as of PR38582 (where rename registers takes 13 hours to do its job).
Closing this as a dup of bug 38582 because that bug has a test case. *** This bug has been marked as a duplicate of 38582 ***