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]
Other format: [Raw text]

Re: [patch] tree-cfg.c: Speed uptree_try_redirect_by_replacing_jump.


On Tue, 2004-11-23 at 14:42 -0500, Kazu Hirata wrote:
> Hi Jeff,
> 
> > > 	* tree-cfg.c (tree_try_redirect_by_replacing_jump): Speed up
> > > 	by restricting to the case with two outgoing edges.
> > Approved.
> 
> Thanks!
> 
> > [ A second thing to investigate would be why we had any
> >   calls to this routine for pr15524 to begin with.  I was
> >   quite surprised to see it in the profile data as I
> >   expected everything to have been threaded at the tree
> >   level for the PR.  ]
> 
> This seems to me a more fundamental problem than speeding up
> redirect_edge_and_branch at the RTL level.
I haven't looked, but for the testcase in question I would have expected
all the jumps to have been fully threaded before we dropped down to RTL.

> I haven't look at redirect_edge_and_branch at the RTL level in
> particular, but I have looked at delete_unreachable_blocks at the RTL
> level to see where unreachable blocks come from.  I've found a couple
> of places that we should be able to easily fix.
delete_unreachable_blocks is an interesting little problem.

There's some micro-optimization that can be done which I know produces
better code on x86 and probably every architecture on the planet.
However, those micro-optimizations are really just papering over
optimizer lameness (particularly alias analysis).  So I'm quite
hesitant to start micro-optimizing that routine.

I don't really see much else that can/should be done for that routine
that would help pr15524 except reducing the number of useless calls.

Jeff


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