On 02 November 2006 01:38, Roger Sayle wrote:
> On Tue, 31 Oct 2006, Dave Korn wrote:
>> Tracking down a gcse bug while unrolling a loop where the count is
>> known to be one, I've narrowed the problem down to the actions of
>> commit_edge_insertions and bypass_conditional_jumps, and I could use
>> a little help in appreciating the reasoning behind what they're /trying/
>> to do.
>
> Sorry for the delay, but I only read the "gcc" list infrequently and
> have only just seen your question.
Sorry for the delay, but it's taken me a little time to dig further into
this :)
> I suspect that somewhere this is falling foul of some other CFG related
> optimization that says if both branches of a conditional jump go the same
> label, then the conditional jump is redundant and can be replaced by an
> unconditional jump. One the CFG believes that BB#2 has only one sucessor,
> then commit_edge_insertions is free to place things there.
I think you're right, and I think I've tracked it down. I think it is
another manifestation of PR13859, which is fixed on mainline since 2004-01-28;
to quote the comment from the patch,
+ /* Avoid unification of the edge with other edges from original
+ branch. We would end up emitting the instruction on "both"
+ edges. */
I was slightly misled for a while by the debug output that says:
----------------------------------<snip!>----------------------------------
Replacing insn 100 by jump 115
JUMP-BYPASS: Proved reg 74 in jump_insn 22 equals constant (const_int 0 [0x0])
Bypass edge from 2->4 to 6
----------------------------------<snip!>----------------------------------
because reg 74 in jump_insn 22 actually is (const_int 1), having just been
incremented; but in fact, it is only the debug output that is incorrect, as it
does not allow for the possibility of the (not) cc-setting insn affecting the
value of the register.
This possibility /is/ correctly allowed for in calculating which way the
branch will go, it's just that the original value of the set found at the end
of the predecessor block is what gets dumped out. The fix for 13859 solves my
bug, although at the cost of leaving the actual loop structure present in the
final output, which isn't perfect, because the compiler should be able to know
that the loop is only going to run once, but it is at least correct.
cheers,
DaveK
--
Can't think of a witty .sigline today....
