On 09/01/14 23:14, Bin.Cheng wrote:
On Tue, Sep 2, 2014 at 11:40 AM, Jeff Law <l...@redhat.com> wrote:
On 08/31/14 22:18, Bin.Cheng wrote:
Note that i0..i4 need not be consecutive insns, so you'd have to walk the
chain from the location with the death note to the proposed death note
site.
If between those locations there's another set of the same pseudo, then
drop
the note. Since this may be an expensive check it should probably be
conditionalized on REG_N_SETS (pseudo) > 1
Here is the complicated part. The from_insn is i1, i2/i3 are the
following instructions. The original logic seems to me is scanning
from i3 for one insn for distribution of REG_DEAD note in from_insn.
Since the last use is in from_insn, it makes no sense to scan from i3
(after from_insn). What we need to do is scanning from from_insn in
backward trying to find a place for note distribution. If we run into
a useless set of the note reg, we can just delete that insn or add
REG_UNUSED to it. It just seems not right to do this on instructions
after from_insn, which causes the wrong code in this specific case.
I wasn't suggesting we add a REG_UNUSED or delete anything. Merely look to
see if between the original note's location and new proposed location for
the note. If there's another assignment to the same pseudo in that range of
insns, then simply remove the note. What happens if you do that?
I will do some experiments on this. If there is no optimizations
depending on the REG_DEAD note following combine pass, I suppose there
is no read effect.
In the case we're talking about, as I understand it, the note no longer
has any useful meaning.
In fact, I can't convince myself there is any valid place to put the
note in the general case and trying to do so is really just a waste of
time. Or to look at it another way, if we were to conceptually throw
away all the REG_DEAD notes, then recreate them from scratch after this
insn combination that there'd be one less REG_DEAD note when they were
rebuilt.
Jeff
