Re: [PATCH] Jump bypassing and improved constant propagation

[Jan Hubicka <jh at suse dot cz>]

> > This I wasn't 100% sure of.  I knew that cc0 was supposed to be
> > dead following the jump instruction.  I was hoping the same was
> > true for CC_MODE, which seems to be backed up on x86 for atleast
> > GCC bootstrap, testsuite and SPEC2000.
> 
> For x86, it's definitely going to be true.  First, the flags are
> modeled with a fixed hard register, which GCSE isn't going to touch.
> Second, virtually everything clobbers the flags, which means that
> even if GCSE did handle hard regs, expressions involving these
> quantities are immediately killed.

I've seen testcases where local cse extended lifetime over the block
boundary on tests of style
if (a<b)
   ...
if (b>a)
   ...

It happends rarely since the CCmodes are usually different, and I am not
sure whether it still happends at all.
> > 
> > I was hoping to get the existing performance improving code reviewed
> > before investigating "redirect_edge_and_branch_force" or the effects
> > of disabling passes or rearranging their order.  If "jump bypassing"
> > was considered inappropriate for GCC there'd be no point in tweaking
> > the implementation.
> 
> I think this idea is definitely promising, don't get me wrong.
> But I think given that you're adding functionality that (partially)
> overlaps existing code, these questions are better asked sooner
> that later.

If I understand this correctly, it handles cases like

if (a==5)
  something
if (a==6)
  something else

Jump threading don't, but jump threading handles

if (a>b)
  something
if (a<=b)
  something else...

This pass don't, or am I missing something?
Value range propagation when done in symbolic domain can obsolette both,
but I am not sure what happent to John's patch.

Honza
> 
> 
> r~