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: [tree-ssa] Minor code rearrangement


On Thu, 2003-10-02 at 14:53, law@redhat.com wrote:
> In message <m34qyrwlgv.fsf@averell.firstfloor.org>, Andi Kleen writes:
>  >law@redhat.com 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) 
    {
      blah;
    }

it would be cool to be able to do them something like:

void blah_func ()
{
  blah;
}

  for_each_bb_in_dominator_order (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...

Andrew


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