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.

I would like to implement the better BB-reordering algorithm then, as
decent implementation is reported to more than change the benefits of
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]