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. > Is the bug perhaps because the bypass code notes that there are two code > paths from BB#2 to BB#7, notices that the indirect one depends on a > condition that it knows is true, but doesn't realise that that doesn't > mean they are equivalent to each other? Aftre reading through your analysis I suspect this is precisely the problem. The jump bypassing code is making the assumption that there can temporarily be two (or more) edges between the same pair of basic blocks. The distinction being that one edge has an instructin inserted on it, and the other one doesn't. 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. Your investigation and understanding is flawless so far. We now need to figure out how these edges are getting merged. If this is a side-effect of recent CFG/RTL related changes jump bypassing might need to be restructured/rewritten to avoid using the insn on edge functionality. Steven Bosscher might even have plans for reorganizing jump bypassing already as part of his CSE/GCSE overhaul? Roger --
