re: Some thoughts and quetsions about the data flow infrastructure

[Kenneth Zadeck <Kenneth dot Zadeck at NaturalBridge dot com>]

>   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.  It
> is a really big improvement (about half year work for all compiler
> team according to Proebsting's law).  IMHO, it could justify promised
> 5% compiler slowness.
>
Vlad, 

I think that different people can have different perspectives.  

You have been working on improving the register allocation for several
years, but very little has come of it because the reload
infrastructure does not suit itself to being integrated with modern
register allocators.  You have spent several years of work without
touching the underlying problem that reload is generally going to
defeat almost any effort to get good benefits out of a new register
allocator.  I do not want to denigrate your work in any way, but at
the end of the day, any new register allocator will be compromised by
the existing reload implementation.

I am interested bringing the rest of the back end into the modern
world.  While some of the passes can and should be moved into the ssa
middle end of the compiler, there are several optimizations that can
only be done after the details of the target have been fully exposed.

My experience with trying to do this was that the number one problem
was that the existing dataflow is in many cases wrong or too
conservative and that it was not flexible enough to accommodate many
most modern optimization techniques.  So rather than hack around the
problem, I decided to attack the bad infrastructure problem first, and
open the way for myself and the others who work on the back end to
benefit from that infrastructure to get the rest of passes into shape.

There are certainly performance issues here.  There are limits on how
much I, and the others who have worked on this have been able to
change before we do our merge.  So far, only those passes that were
directly hacked into flow, such as dce, and auto-inc-dec detection
have been rewritten from the ground up to fully utilize the new
framework.  

However, it had gotten to the point where the two frameworks really
should not coexist.  Both implementations expect to work in an
environment where the information is maintained from pass to pass and
doing with two systems was not workable.  So the plan accepted by the
steering committee accommodates the wholesale replacement of the
dataflow analysis but even after the merge, there will still be many
passes that will be changed.

I would have liked to have the df information more tightly integrated
into the rtl rather than it being on the side.  It is cumbersome to
keep this information up to date.  However, the number of places in
the backends that depend on the existing rtl data structures apis make
such a replacement very difficult.

I do believe that by the time that we merge the branch, we will be
down to a 5% compile time regression.  While I would like this number
to be 0% or negative, I personally believe that having precise and correct
information is worth it and that over time we will be able to remove
that 5% penalty.  

As far as the other regressions, these will be dealt with very soon.  

Kenny