This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Jump bypassing and improved constant propagation
> > 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
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
Jump threading don't, but jump threading handles
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.