This is the mail archive of the gcc-patches@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]

Re: crossjumping over CFG


> On Sat, Jul 07, 2001 at 01:37:39PM +0200, Jan Hubicka wrote:
> > Implements cross-jumping on the flowgraph.
> 
> Hmm.  I'd always thought about replacing the jump nastiness with
> a proper code hoisting pass (with sinking being done by hoisting
> on the post-dominators rather than the dominators).
Hmm, I expect I know what are you speaking about, but do you
have some pointers to description of the code hoisting you do
have in mind?
> 
> I suppose this is sort of complimentary, in that code hoisting
> would never insert new jumps -- only move code into existing
> post-dominators.  Which loses opportunities when there are lots
> of edges incoming to a common destination block but only some
> edges share code.
I tought that the crossjumping as it is now can be kind of temporary,
but it is important step to blast of the current jump pass (I need
to extend CFG lifetime and have jump in the way) and it gives good
testing the the CFG infrastructure, as jump redirection and such.
> 
> There's a lot of new code here.  I'd prefer to see this run on
> a couple of machines before going in.
OK, I will try it in sparc/mips at monday. Is that OK?
I did sucesfull test with ppc simulator with older version of the patch.
> 
> > +       /* Don't allow old-style asm or volatile extended asms to be accepted
> > + 	 for cross jumping purposes.  It is conceptually correct to allow
> > + 	 them, since cross-jumping preserves the dynamic instruction order
> > + 	 even though it is changing the static instruction order.  However,
> > + 	 if an asm is being used to emit an assembler pseudo-op, such as
> > + 	 the MIPS `.set reorder' pseudo-op, then the static instruction order
> > + 	 matters and it must be preserved.
> > + 
> > +         ??? Does this still hold?  We reorder insns in many other
> > + 	parts of compiler w/o extra care.  */
> 
> This is attempting to preserve intended behaviour for
> 
> 	asm(".set noreorder");
> 	asm("foo");
> 	asm("bar");
> 	asm(".set reorder");
> 
> It's well documented that this is not supported:
> 
> #    Note that even a volatile `asm' instruction can be moved in ways
> # that appear insignificant to the compiler, such as across jump
> # instructions.  You can't expect a sequence of volatile `asm'
> # instructions to remain perfectly consecutive.  If you want consecutive
> # output, use a single `asm'.
OK, can I blast it off then?

Honza
> 
> 
> r~


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