Re: [RFC] fold Reorganization Plan

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

Hi Nathan,

> hm, we may be in violent agreement :)  It depends what you mean
> by 'early fold'.  You say it would handle constant expressions for FEs
> -- isn't that the same as what I described as a constant expression
> evaluator?

Yes.

> After all, if it is just for constant exprs, it is required
> to 'fold' to a _CST node -- or give an error.  If I've misunderstood,
> could you clarify?

Can a compile-time constant appearing in an initializer be as wild as
the following?

  0 ? (foo () + 9) : (3 + 5)

Here (foo () + 9) does not fold to a constant, but the whole
expression does fold to 8.

> > 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.
> Do you have examples of what this would be?

Certainly, a GIMPLE-specific fold wouldn't need to handle
TRUTH_ANDIF_EXPR.  I cannot come up with a better example right now.
TRUTH_ANDIF_EXPR wouldn't be a good example because we are just
removing one case of the big switch statement in fold, which is
unlikyly to give any measurable speed-up.

> I have no feeling for what might be foldable in GIMPLE.  I'm curious
> (I don't think it'll affect the discussion though).

x & x  ->  x ? :-)

> hm, there's really two kinds of thing that need to happen,
> 1) the kind of reassociation & strength reduction that you describe
> 2) folding of constant expressions, for when we discover that some of
> A, B and C are constants.
> 
> I don't know whether these operations should be part of the same SSA
> optimization or not. #2 is more of a constant propagation kind of
> thing I guess. #1 is the kind of thing that has made const-fold so
> complicated. #1 is the important thing to add to the SSA optimizers,
> isn't it?

Yes.  Some transformations that happen in fold would involve CFG
manipulation in the GIMPLE world.  Those transformations include
TRUTH_{AND,OR}IF_EXPR, a lot of COND_EXPR manipulations, etc.  If
these are good transformations, we need to move them to the SSA
optimizers as you mentioned..

Kazu Hirata