Re: [RFC] fold Reorganization Plan

[Kazu Hirata <kazu at cs dot umass dot edu>]

Hi Nathan,

> I question if it is better to fold early.  As I've said before, I think
> the optimizations that fold performs should be turned into a proper SSA
> optimization phase% -- that can be repeatedly applied as necessary.  In the
> front end, folding should not generally be done.  I see two needs for
> early folding,

I may not be quite answering your question, but I have a comment.

Maybe we can have an early fold and a general fold.  The former would
handle constant expressions for front ends.  The latter is a full
fledged version but optimized to handle GIMPLE statements.

The reasons to optimize the full fledged version to handle GIMPLE
statements include

1) We can remove parts of fold handling those cases that never occur
   in the GIMPLE world.

2) Currently, fold has so many transformations that look into a
   heavily nested tree, but all of those are useless in the GIMPLE
   world unless one builds scratch node and passes it to fold.  An
   example of such a transformation would be:

   (A * C) + (B * C) -> (A + B) * C

   We would express this in GIMPLE as

   D = A * C;
   E = B * C;
   F = D + E;

   Given D + E, we can instead have fold chase SSA_NAME_DEF_STMT of D
   and E so that the above transformation is performed.  Whether we
   want to always chase SSA_NAME_DEF_STMT is another question.

   Richard Henderson once suggested putting a hook for chasing.  In a
   tree combiner, we may want to limit SSA_NAME_DEF_STMT chasing to
   the case where the SSA_NAME is used only once.  In other
   situations, we might want to have a more relaxed hook although I
   cannot come up with a specific example.

Kazu Hirata