This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Minor code rearrangement
- From: Andrew MacLeod <amacleod at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: Andi Kleen <ak at muc dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: 02 Oct 2003 15:04:11 -0400
- Subject: Re: [tree-ssa] Minor code rearrangement
- References: <200310021853.h92Ir5Ji010252@speedy.slc.redhat.com>
On Thu, 2003-10-02 at 14:53, firstname.lastname@example.org wrote:
> In message <email@example.com>, Andi Kleen writes:
> >firstname.lastname@example.org writes:
> I can also certainly envision at least one optimizer that is going to want
> to do a dominator tree walk, but which can not be merged with the existing
> walks. Fundamentally, it can't co-exist with the existing dominator
> optimizer, but it wants to be able to use certain capabilities of the
> existing dominator optimizer.
There are a few things that would benefit from processing basic blocks
in dominator order too. So instead of
it would be cool to be able to do them something like:
void blah_func ()
Then I know I will have visited as many predecessors as possible before
visiting each basic block. Initialization in CCP for instance.. One of
the big speedups was processing blocks in a breadth first manner instead
of the original depth_first manner. Dominator order is even more ideal.
I can think of other places I would like to do that sort of thing, as
long as its not much more time consuming than FOR_EACH_BB()... In fact,
I even mentioned it to Diego a week ago ro so as something desirable :-)
And clearly there are even better things we can do with it...