This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: GCSE again: bypass_conditional_jumps -vs- commit_edge_insertions - problem with ccsetters?


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.

  No apologies needed, I very much appreciate your input.

>> 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.

  Right.  For the moment, I've just done this:

@@ -4816,19 +4921,34 @@ bypass_conditional_jumps ()
 	      }
 	    else if (GET_CODE (insn) == JUMP_INSN)
 	      {
-		if (any_condjump_p (insn) && onlyjump_p (insn))
+		if (any_condjump_p (insn) && onlyjump_p (insn)
+#ifndef HAVE_cc0
+            && !setcc
+#endif
+            )
 		  changed |= bypass_block (bb, setcc, insn);
 		break;
 	      }
 	    else if (INSN_P (insn))
 	      break;

to completely disable the bypassing when any instruction would need to be
inserted on the edge.  I think that's suboptimal, it should be ok if there are
no *other* edges between the same two blocks but I don't know how to test that
yet.

> 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.

  So far I haven't been able to reproduce this on 4.x; I've only seen it on
3.3.3 with a (custom) non-cc0 backend and I only have an x86 build of trunk.
I've had a thorough browse through bugzilla and haven't found any similar bug
or related fix, so it may well be one of those things that is still there but
doesn't trip any more because of tree-ssa doing so much work before the rtl
optimisers get called.  I'll see if I can reproduce it on a cross ppc build of
trunk.


    cheers,
      DaveK
-- 
Can't think of a witty .sigline today....


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]