This is the mail archive of the gcc@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: GCC 3.5 Status (2004-08-29)


On Mon, 2004-08-30 at 01:34, Steven Bosscher wrote:
> Also, I believe the edge-vector-branch work is also purely a speedup
> project - it will make looking up PHI arguments much faster.  As I
> have shown before on this mailing list, this is one of the major bottle
> necks for passes like DOM.
The edge-vector stuff is definitely a good thing.  However, I would
not expect a big benefit from it.

Yes, there are certain codes where it would speed up DOM in a 
meaningful way, but in general I don't expect you'll find that it's
a big improvement.  I like the edge-vector work because it means
we can rip out the hacks which we added to prevent the traversal
of the PHI arguments from becoming a huge time sink.

Speeding up DOM in the general case at this point means finding a
way to stop iteration.   Not surprisingly I've thought quite a bit
about that problem.

I haven't started any experiments, but my theory is that the cases
were iterating DOM is useful can be detected by the existence of
optimizable PHIs.

ie, if we have a degenerate PHI such as this after DOM

a1 = PHI (a0)   -- or
a1 = PHI (a0, a0) -- or
a1 = PHI (a0, a1)

Then iterating DOM may be useful.  I suspect (but certainly haven't
confirmed) that iterating if no such PHIs are found is relatively
pointless.

So we might be able to reduce iteration steps.  That would be good.
Again, I haven't played with this yet, so it's ripe for someone
to poke around.

Beyond that I've spent considerable time thinking about how to
remove the iteration step completely, but it's probably not
worth outlining those thoughts at the moment as they are
predicated on the concept that optimizable PHIs are the key to 
determining what (if anything) might be gained by iterating DOM.

Jeff


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