This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] Minor code rearrangement
- From: law at redhat dot com
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: Andi Kleen <ak at muc dot de>, gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Thu, 02 Oct 2003 13:56:00 -0600
- Subject: Re: [tree-ssa] Minor code rearrangement
- Reply-to: law at redhat dot com
In message <1065121453.5274.90.camel@p4>, Andrew MacLeod writes:
>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
> FOR_EACH_BB (bb)
>it would be cool to be able to do them something like:
>void blah_func ()
> for_each_bb_in_dominator_order (blah_func);
That's pretty easy with the scheme I'm looking at. You just have to store
blah_func into the appropriate slot in the datastructure you pass to the
The appropriate slot of course determining if you want to call blah_func pre
or post-order. You'd leave NULLs for the other callbacks.
>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 :-)
Unsure if it'll be faster or slower than FOR_EACH_BB (OK, the base walker
will be slower, I'm assuming that we'll make up for some of that by doing
things in a better order).
If you're going to be doing a lot of dominator walks, you might just want
to get a list of the blocks in dominator order and iterate through them.
Or, hell, we might consider re-wiring the BBs so that FOR_EACH_BB presents
them in dominator order. Dunno.