Kazu,
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.
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? 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?
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? I have no feeling for
what might be foldable in GIMPLE. I'm curious (I don't think
it'll affect the discussion though).
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
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?
nathan
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
[EMAIL PROTECTED] :: http://www.planetfall.pwp.blueyonder.co.uk
