On 2/12/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
On Sunday I had accidentally chat about the df infrastructure on
IIRC. I've got some thoughts which I'd like to share.
I like df infrastructure code from the day one for its clearness.
Unfortunately users don't see it and probably don't care about it.
With my point of view the df infrastructure has a design flaw. It
extracts a lot of information about RTL and keep it on the side. It
does not make the code fast. It would be ok if we got a better code
quality. Danny told me that they have 1.5% better code using df.
I also said we hadn't run numbers in about a year and a half, because
it wasnt our main goal anymore.
...
especially if we have no alternative faster path (even if the old live
analysis is the mess).
I also pointed out that df's merge criteria are no more than 5%
compile time degradation.
So what are you worried about here?
Life analysis isn't just a mess, it's inaccurate, and intertwined
with dead store elimination and dead code elimination.
Even rewriting the current optimizations on the new data flow
infrastructure makes situation worse because it will be not easy to
rid off the data flow infrastructure because probably part of the flaw
in the df interface.
What?
The flaw we have now is that every pass creates it's own
datastructures and dataflow, and is complete impossible to make
dataflow faster without rewriting every single pass.
With DF, you could make every single pass faster simply by improving ... DF!
If the datastructures it has don't work well enough for any pass of
course, you can add your own as df problems and results.
So it might create problems in the future.
Especially I did not like David Edelhson's phrase "and no new
private dataflow schemes will be allowed in gcc passes". It was not
such his first expression. Such phrases are killing competition which
is bad for gcc. What if the new specialized scheme is faster. What
if somebody decides to write another better df infrastructure from the
scratch to solve the coming df infrastructure problems.
If you want to rewrite DF, please do.
But honesty, GCC has enough separate solvers that simply are not
faster anymore than df branch's solver. We know. We replaced a lot of
them.
And that's the thing. We had to go and replace every single one of
these, when if they had just used df's solver in the first place (and
taken the 1-2% slowdown they probably faced), they would all just have
been sped up.
Worse, some of these solvers were buggy or inaccurate, so now that we
give it better information, faster, we have to go fix bugs that never
would have existed had they reused the infrastructure we provided.
This is in fact, a lot of what has taken up df branch time. Fixing
bugs that fixing the dataflow exposed.
I am not in opposition to merge if it satisfies the merge criteria.
People've done a lot of work. It is too late. I've should oppose the
criteria when they were discussed. Sorry I've missed the discussion
if there were such discussion. I am just rising some questions and
saying that more work will be needed for df-infrastructure even after
the merge.
There is always more work to be done.
BTW, I'll happily remove DF when all that is left of RTL is the
scheduler, RA, and instruction selector.
Hell, i'll throw a party.
But i wouldn't hold your breath for this to happen. :)
--Dan
