http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48773
Summary: Dataflow and REG_DEAD notes
Product: gcc
Version: 4.3.5
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mfort...@gmail.com
Hello all,
I have recently been updating an out of tree target from GCC 4.2.4 to GCC 4.3.5
and have noticed that REG_DEAD notes can get out of sync at the end of multiple
passes. (i.e. be attached to instructions where the register does not die)
The first pass that appears to get REG_DEAD notes out of sync is GCSE. This
gets fixed and broken multiple times as some of the later passes solve the DF
note problem via df_analyze, some delete all notes and some get the notes out
of sync again. When the second schedule pass (sched2) runs the DF note problem
is solved at the start but then instructions can be re-ordered and notes are
once again left out of sync. In my case this causes (an admittedly old)
peephole to be applied incorrectly and bad code is generated.
It seems to be that each pass, which may get notes out of sync, should run the
note problem before finishing.
With some experimentation I have seen that running df_analyze to solve the note
problem at the end of some passes leads to an apparent improvement in the code.
It would therefore seem that some passes use REG_DEAD information without
first solving the REG_DEAD problem. This sounds reasonable as I would expect
each pass to end leaving notes valid.
Is the behaviour I have described here intentional? If so, could someone
explain the rationale? I can't see any changes in this area (up to trunk) and I
have seen REG_DEAD notes get out of sync with at least one in-tree target for
which I could provide a testcase if that is useful (GCC 4.5.1). This issue is
quite general though so I believe a large amount of code should trigger the
notes to get out of sync. This clearly does not lead to actual bugs in most
cases otherwise it would have already been reported.
regards,
Matthew
