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: [patches] Re: crossjumping over CFG


> > On Sun, Jul 08, 2001 at 11:15:52AM +0200, Jan Hubicka wrote:
> > > BTW how much problems do you expect from killing such thinks
> > > as LABEL_NUSES, barriers, automatical removing of dead code at
> > > flow_delete_insn and such beasts?
> > 
> > Lots.  It'll be quite nasty.
> Me too.  For start I would loke to kill the automatical removing, that may not
> bring too much troubles and LABEL_NUSES next.
> I am affraid of barriers especially.
> > 
> > > Just to ensure, assuming it passes the tests (I hhope so now after
> > > fixing the redirection code), can I consider patch approved?
> > 
> > Um, ok I guess.  Are you going to work on block duplication
> > code for bb-reorder then?  Otherwise, perhaps we ought just
> Yes. Post-bb-reorder at the moment.
Basically I want to provide easy to use infrastrcucture to handle CFG including
the bb duplication, so we can then do loop peeling, tracer or loop unroller
more naturally than we are doing now.

Jump rewrite is kind of test what infrastructure bits are needed, still work
with CFG is nasty. From major part because of old jump infrastructure mentioned
above, that kind of doubles the information needed to update at each emit.
> 
> I would like to implement the better BB-reordering algorithm then, as
> decent implementation is reported to more than change the benefits of
						 ^^^^^^ double
> reordering.
> 
> For for that I need the counts and frequencies, for that I need CFG survive
> from flow1 pass, for that I need fix reload and post-reload splitting, that may
> get tricky, as we may introduce new jump insns.  So I don't want to run into
> too much details at this moment. Death of jump2 pass is my goal at the moment.
> 
> BTW currently I didn't measured any noticeable slowdown.  Trick is that
> bb-reorder does good job on avoiding branches on critical path.  Actually it
> brings speedups, as code size decreases over original implementation.
> > have this on for -Os?
> Even -Os overactive crossjumping is sometimes loss.
> 
> Honza
> > 
> > 
> > r~


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