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 constant propagation

Hi Richard,
On Sun, 26 May 2002, Richard Henderson wrote:
> On Sat, May 25, 2002 at 01:02:21PM -0600, Roger Sayle wrote:
> > Being a single block by the time this reaches GCSE, there's nothing
> > that the jump bypass optimization can do to reduce it.
> There are pros and cons here.  On the one hand, it's possible to
> hoist "z=(x==y)" whereas "if (x==y) z=1; else z=0;" cannot be moved.

I'm sure you realize, but its not that it "cannot be moved", but
rather that it "isn't currently moved" or is "much harder to move" :>
The CFG subgraph "if (x == y) u=1; else v=0;" can be hoisted out of
a loop provided that x, y, u and v are not modified elsewhere in the

> One thing to check is how placement of if_convert affects loop.  The
> existing code doesn't understand the CFG and has some, err, interesting
> heuristics that it picks up from wanderint around jumps.  Thus I have no
> trouble believing that a loop with no internal branches can be optimized
> better that a loop with an embedded if/then/else.

Dare I mention PR opt/6405 which was in response for your "Request
for Regressions" ?

> > - #ifdef HAVE_cc0
> Err, so what are you replacing this with?

and also...

> > + 		  rtx dest = SET_DEST (PATTERN (insn));
> > + 		  if (GET_MODE_CLASS (GET_MODE (dest)) == MODE_CC)
> > + 		    changed |= bypass_block (bb, insn, NEXT_INSN (insn));
> Why are you so hot on CCmode?

It may just be my misunderstanding but I was hoping to extend the
existing "#ifdef HAVE_cc0" to targets such as x86, that don't have
a single cc0_rtx, but instead several MODE_CC registers that are set
immediately before a conditional jump.  I'd assumed, perhaps very
incorrectly, that "GET_MODE_CLASS (GET_MODE (cc0_rtx)) == MODE_CC"
making the current code a simplified superset of the original.

Let me know if I still need "#ifdef HAVE_cc0".

> What if the target uses DImode comparisons to feed the jump
> insn (e.g. alpha)?

Unfortunately, CVS isn't bootstrapping for me on alphaev67-dec-osf5.1
at the moment.  How are DI mode comparisons handled on the alpha
and similar architectures?  [I'll investigate at work tomorrow].

> My only guess is that you are under the impression that CCmode
> registers are guaranteed to be dead at the ends of blocks.
> Which is often true, but in general false, as discussed above.
> So your test really wants to be "is SET_DEST (setcc) consumed by
> the branch".  For this you need (ideally) bb->global_live_at_end
> or (not-as-ideal) REG_N_REFS(regno) == 2, neither of which are
> valid at this time.
> I think you're going to have little choice but to run this as a
> separate pass after having updated life info.

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.  My contingency if this
turned out not to be the case, was to use insert_insn_on_edge
to place a copy of the original "setcc" on the redirected edge.
If it transpired that the condition code wasn't used, the insn
would be marked dead and cleaned up later.  The worry was that
inserting insns on each edge in the hope that they'd be cleaned
up would slow down the compiler, especially if they were never
actually required.

Would this be a simpler approach than interacting with life
analysis?  Can the limited lifetimes of CC_MODE registers be
guaranteed in early passes (GCSE) or on some platforms?

> One more thing: have you checked to see if this completely obsoletes
> thread_jump?  If so, we can delete it.  If not, which cases are still
> caught by the old code?  Are there enough remaining to justify the
> time spent?

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'm really just a beginner at this; You, Jan and
Jeff appear to be the real experts.

I'm reworking my patch to implement all of your above suggestions.
It appears that the existing constant propagation pass in "cprop"
wasn't an ideal starting point to base my modifications upon.

I greatly appreciate your review and help.

Roger Sayle,                         E-mail:
OpenEye Scientific Software,         WWW:
Suite 1107, 3600 Cerrillos Road,     Tel: (+1) 505-473-7385
Santa Fe, New Mexico, 87507.         Fax: (+1) 505-473-0833

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