This is the mail archive of the 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: [PATCH] Jump bypassing and improved cprop (take 2)

> On Sun, Jun 02, 2002 at 11:01:10PM +0200, Jan Hubicka wrote:
> > > Could you explain why the additional clobbers aren't valid when
> > > copied to the redirected edge?  I must admit that this aspect
> > > of the changes to my original patch is almost beyond me.  I'd
> > > have thought that even if the values are no longer clobbered,
> > > its still safe to claim that they are.
> > 
> > The clobbers may kill value otherwise live on the edge, so change
> > semantics of code in a way you don't want to.
> > This is partly cared by my hoist_insn* bits that checks for such
> > side effects and verifies wehther the move is valid.
> No, actually he has a point, which I hadn't considered until now.

I noticed that after sending email too.
In Czech we say something like twice measure before cutting, I usually
cut first...

> The original code is like
> 	a:
> 	  ...
> 	  if (p) jump b
> 	...
> 	b:
> 	  t = r op c
> 	  if (t) jump c
> I.e.
> 	A
>        / \ /
> 	  B
> 	 / \
> 	C
> The point of the excercise is to redirect the A->B edge to A->C
> based on knowledge of R at the end of A.  Thus the revised flow is
> 	A
>        /|  /
> 	| B
> 	|/ \
> 	C
> Except that since we don't know the true lifetime of T, we have
> to copy that operation onto the A->C edge.  Most of the time T is
> actually dead, and thus the copied operation can be deleted later.

I see now, kind of transformation tracer does as well.

> Otherwise the transformation isn't much of a win since we are in
> effect duplicating block B.  I think that just about all of these
> cases can be fixed by a later cross-jump pass, so I wouldn't
> complicate the code here by worrying about it.

> The point of contention just now is whether or not it is valid to
> move the clobber that might be associated with OP onto that edge.
> The answer is yes.  The reason is that the original control flow
> *always* passed through that instruction via the A->B->C path.
> Thus whatever value might be clobbered by OP, it for certain was
> not previously live on entry to C.

I am just looking at the code.  It may be interesting to put it into
some reusable part, as jump threading, ifcvt and few other places
touches similar problem. I will deifnitly take closer look later.

Note that there is at least one out-of-date comment mentioning
stable BB indices

> r~

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