Re: Some 4.4 project musings

["Richard Guenther" <richard dot guenther at gmail dot com>]

On Feb 1, 2008 9:55 PM, Andrew MacLeod <amacleod@redhat.com> wrote:
>
> There are a few things that I'm considering working on for the 4.4
> release, and I figured I'd see what others thought.  Is anyone
> considering/doing similar or related work?
>
> I'll summarize each, and then go into more details.

> Pass Cleanup
> -----------------
>
> It would sure be nice to streamline our pass pipeline.  One could spend
> the rest of ones life doing this by hand. The 2 biggest problems would
> seem to be:
>  * we have no idea whether a pass actually does much
>  * and we have no idea whether it was actually useful

I would add

 * re-ordering passes makes the compiler break

so we need to uncover existing bugs by doing some re-ordering experiments.

What I'd like to do very early in 4.4 is

 - run those cleanups that are run after first may_alias pass (mainly
ccp, copyprop
   and forwprop) right after the final inlining, but before the first
may_alias pass.
   This will reduce the amount of pointers and addressable vars we
need to process
    in may_alias (which helps my goal of reducing the number of VOPs,
see also below)

 - go into-SSA even for -O0, mainly to
    * run TER at -O0, improving initial rtl code quality
    * remove paths in the middle-end that are double, like SSA inlining and
       non-SSA inlining, TER/non-TER expansion

 - do gimplification unit-at-a-time to allow IL lowering at a point
the TU is complete
   (this will be the last chance to call back to the frontends)

 - output (some) debug information early, mainly everything that is FE
dependent such
   as types and decls;  this enables us to lower datastructures of
decls and types to
   a middle-end representation (no more trees, wheeee)


> Interface to Virtual Operands
> -------------------------------------
>
> I'd like to do a survey of all the optimizations which use virtual
> operands to see how they use it and how they manipulate it. From that,
> we can extrapolate the kinds of questions that are asked and the kinds
> of manipulations that are performed. In particular look for slight
> variations in the interpretation or manipulation of the VOP data.
>
> Until that survey is done, its hard to predict what the interface
> routines would be. There are certainly a base set such as
>  * can a load/store to B be inserted before/after this stmt
>  * can a load/store from B be moved from stmt1 to stmt2 safely
>  * if not, which stmt(s) are the blockers
>  * insert a store to B.
>  * etc, etc.
>
> The survey would help fill out this list and identify commonly done
> tasks and needs. We do enough stuff now that it would make a pretty good
> representational data set I think.
>
> I expect some passes hold a modified state within the pass which isn't
> reflected in the VOP web. The interpreter could maybe hold an internal
> modified state as well where the interface allows a pass to say 'I'm
> pretending to insert this stmt , and that stmt is fake-deleted'. It
> would then allow the queries to reflect the situation based on these
> modifications.  This state could be a state stack if need be for
> unwinding changes.  This would prevent optimizations from having to take
> care of all this crap themselves, and simplify maintenance and future
> coding.
>
> That might turn out to be quite difficult, its hard to say without the
> initial survey of what and how things are done.  We certainly have
> enough passes using the information now that we can get a feel for what
> common ground there is for interpreting the VOP web.
>
> In thinking about a pressure reduction pass for instance, it would be
> much simpler to write it if these facilities were in place as general
> routines, even if it were just the query routines.  I'm assuming Richi's
> oracle would address some of this?

My priority here is to get rid of SFTs and all the complexity (in memory
and compile-time) they cause.  Passes that do optimizations on stores/loads
will be enhanced to cope with very imprecise virtual operand chains,
thus mainly use it for efficient walking of interesting stmts.  FRE is ready
(there are some general issues with SCCVN and I didn't yet look at PRE),
we also have a patch from Zdenek for load/store motion in loops.


I share the feelings about SRA and I would add that we need a replacement
implementation for DSE.

Richard.