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.
Thanks, bin > > It seems to me that adding a REG_UNUSED or trying to delete any insns at > this stage is just a complication we don't really need. > > jeff
