Re: dataflow branch merging plans.

[Jan Hubicka <hubicka@ucw.cz>]

> "Vladimir N. Makarov" <vmakarov@redhat.com> writes:
> > <stevenb> honza: you know vlad... he has great ideas, in theory, but there's a reason why he never manages to actually finish something properly ;-)
> > <honza> hmm, for example dfa automatos does their job relatively well...
> > <stevenb> ...if you're willing to accept that:
> > <stevenb> a) it takes 30% of the total compile time
> > <stevenb> b) all the good parts are written by zack
> > <stevenb> c) all the scheduler descriptions except itanium are written by me
> > <stevenb> (oh, and mips, which paolo bonzini took care of)
> 
> I know this wasn't meant to be taken seriously, but since Vlad has
> already dissed (a) and (b), I don't think (c) is true either.

Because I was quoted above, I guess I should also add that I like the
Vladimir's work.  I familiarized myself with the automaton generation
code when I needed to speed it up to get Athlon machine description
generated in resonable time and I think I know what I am speaking about
when I say that it is very nice piece of work. It was definitly hard to
implement and the problems that occured after merge was relatively
little given the complexity of project (and I probably should've
commented more on the IRC originally).  Overall I think Vladimir work is
of very good quality, a lot of it seems to end up unmerged because it
don't seems to meet orignal expectations that might be a pity as the
code might be useful anyway. (However not every developer has enought of
discipline to drop a code he spent a lot of work on when it don't seems
to do what it was supposed to very well.) DFA or new YARA are definitly
dificult projects and I am happy we have someone who can track them
down.

In general it seems to me that there is a conflict of development
philosphies.  While Vladimir is trying to get his project done to the
degree that they are stable and overall win before merging, proposed
dataflow merge is on different basis.  Main motivation for dataflow
merge seems to be that there seems to be overall agreement that we want
a new dataflow implementation and further delaying the merge don't seem
to make it significantly more ready.  It up to us, other developers,
whether we want to take responsibility to get it done for 4.3 to the
level so it is not causing compilation time, memory or wrong code bugs.

This scheme seemed to wrok for tree-SSA and might be only way to deal
with some of very dificult projects.  (Even though I am trying to merge
my larger projects when they are done, I had similar merge with original
cgraph unit-at-a-time implementation that caused a lot more problems
that I would anticipated at that time). So I would suggest to give it a
try with dataflow too. I see only other sensible option to drop it
completely that would be IMO a considerable mistake, as we will need to
modernize RTL backend sooner or later and there don't seem to be
anything fundamentally wrong with dataflow branch design as far as I can
tell. So as I admire the Vladimir's work, I admire the efforts put to
dataflow as well.

Honza