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 Oct 2, 2003, at 3:04 PM, Andrew MacLeod wrote:


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);

That would be nice.


It would be nicer if we could just macro it rather than function it.
Can't we sort the bb linked list, or does a lot of stuff depend on it being in 1...n order?


I've got a linked list memory sort that would do it if it's not gonna screw other things up.

Though i'd settle for a for_each_bb_in_dominator_order.
--Dan


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