Bug 29854 - reload_combine looses track of uses
Summary: reload_combine looses track of uses
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on:
Blocks: 29842
  Show dependency treegraph
 
Reported: 2006-11-15 21:12 UTC by Jorn Wolfgang Rennecke
Modified: 2016-03-19 01:49 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2008-12-28 22:07:33


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jorn Wolfgang Rennecke 2006-11-15 21:12:05 UTC
When reload_combine replaces a register with a sum of
another register ('base') and a constant, it fails to
note the new uses of the base.  Thus, when it later
replaces the base, thew new uses won't be updated.

A patch is here:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01387.html
Comment 1 Thomas Koenig 2008-12-26 16:02:42 UTC
Is there a test case which shows the wrong-code
behavior, and which can be checked against the
new register allocator?
Comment 2 Jorn Wolfgang Rennecke 2008-12-27 12:16:47 UTC
(In reply to comment #1)
> Is there a test case which shows the wrong-code
> behavior, and which can be checked against the
> new register allocator?

I don't know of any particular test case.  If you
want one, I suggest to compile the SH linux kernel
with and without the patch and diff the assemply
output of the compiler.
You could also try looking in Toshi Morita's
stress testsuite, or any other code that is heavy
with reloads and large stack frames.
Comment 3 Thomas Koenig 2008-12-28 16:44:30 UTC
Is this still an issue with current trunk, or
with 4.3?

If that's the case, please add a test case,
with preprocessed source (even if it is very large)
showing the problem.
Comment 4 Jorn Wolfgang Rennecke 2008-12-28 22:07:33 UTC
(In reply to comment #3)
> Is this still an issue with current trunk, or
> with 4.3?

I had a look at the current trunk and the diffs leading up to it, and I can
confirm that the issue has not been fixed.
However, I don't have any specific test case.

Note also that for this kind of bug you can expect test cases to be
- very large and hard to understand
- appearing and disappearing in a pseudo-random manner as you make prima facie
  unrelated changes to other passes.
- For the trunk, or any branch with significant activity, it is likely that
  it takes longer to find a testcase than it takes that testcase to become
  obsolete because of some new check-in.
Comment 5 Thomas Koenig 2009-12-16 17:27:10 UTC
A test case is still required.
Comment 6 Oleg Endo 2016-03-06 15:01:47 UTC
(In reply to Jorn Wolfgang Rennecke from comment #0)
> 
> A patch is here:
> http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01387.html

And the latest feedback for that was this:
https://gcc.gnu.org/ml/gcc-patches/2006-01/msg01473.html


Looking at the current code in postreload.c, it seems that the patch somehow made it into mainline at some point.  Although some of the lines now look a bit different.  Can we close this PR as "works for me"?
Comment 7 Kazumoto Kojima 2016-03-06 23:54:22 UTC
(In reply to Oleg Endo from comment #6)
> Looking at the current code in postreload.c, it seems that the patch somehow
> made it into mainline at some point.  Although some of the lines now look a
> bit different.  Can we close this PR as "works for me"?

That sounds reasonable.
Comment 8 Jorn Wolfgang Rennecke 2016-03-08 19:24:38 UTC
revision 149282:

2009-07-06  J"orn Rennecke  <joern.rennecke@arc.com>
            Kaz Kojima  <kkojima@gcc.gnu.org>
 
        PR rtl-optimization/30807
        * postreload.c (reload_combine): For every new use of REG_SUM,
        record the use of BASE.
Comment 9 Oleg Endo 2016-03-19 01:49:29 UTC
(In reply to Jorn Wolfgang Rennecke from comment #8)

Thanks for the clarification, Jörn.