This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Temporary Expression Replacement in SSA->normal.

In message <>, Roger Sa
yle writes:
 >I don't disagree that many of the extremely important optimizations
 >performed during RTL expansion could be performed earlier during
 >tree-ssa.  The pragmatic problem, addressed by Andrew's patch, is that
 >the current situation is that these optimizations are neither performed
 >by tree-ssa, nor by RTL expansion of lowered GIMPLE, which results
 >in a significant performance penalty.

I'll also point out that it is our intention to move those optimizations
to an earlier point in the compiler as they are identified.

What worries me is that we're going to find that the optimizations which
matter and which are necessary to one day make temporary expression
replacement die are going to be precisely those which require looking
at arbitrarily complex expressions rather than those which can be
found by looking at gimple expressions.

My personal plan all-along to deal with that has been to have a tree
combiner which has a lot of properties similar to the RTL combiner.

 >Indeed, the reason that tree-ssa generates worse code than mainline,
 >even with all of the existing RTL optimizers still enabled, is not
 >because SSA itself serious pessimizes the code "per se", but from a
 >mismatch between the kinds of trees it expands, and those that the
 >RTL optimizers are used to optimizing.
In some cases, you're right.  In other cases the SSA code does
pessimize code :( We're working on that :-)

 >Sometimes, the best tree representation of performing transformations
 >and optimizations is not the same as the most efficient to execute.
 >For example, we can combine and factor multiplications and array
 >references easier if they are represented as multiplications and
 >array references, but they are executed more efficiently, as shifts
 >and additions and pointer arithmetic.
[ ... ]
Which highlights another general problem.  In RTL we have canonical
ways of representing a lot of things.  Trees don't have that kind of
rigor yet.  This ultimately results in a fair amount of complexity or
duplicated code in the folders/optimizers.

Standardizing on canonical forms for things which can be expressed in
will help this situation to some extent.

 >> This should be trivial for SSA CCP, no?  Which is again an argument
 >> for doing these transformations while we still have SSA form
 >> available.
 >I'll admit that I'm not sure.  If SSA CCP can optimize
 >T.1 = A + B
 >T.2 = T.1 + C
 >T.3 = T.2 + D
 >T.4 = T.3 - A
 >then I'd be impressed.  It's not impossible, just that I don't think
 >that deep reassociation is currently implemented.  I may be wrong.
We certainly don't implement reassociation.  That would be the job of
the tree combiner since ultimately I'd prefer it to be the place
where we do most of the following of use-def links to build larger
non-gimple expressions, then simplify them into something more reasonable.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]