Some thoughts and quetsions about the data flow infrastracture
Tue Feb 13 04:56:00 GMT 2007
On 2/12/07, Vladimir Makarov <firstname.lastname@example.org> 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.
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
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. :)
More information about the Gcc