This is the mail archive of the
mailing list for the GCC project.
Re: [tree-ssa] fold each statement
- From: Jan Hubicka <jh at suse dot cz>
- To: Richard Henderson <rth at redhat dot com>, Jan Hubicka <jh at suse dot cz>,gcc-patches at gcc dot gnu dot org, law at redhat dot com
- Date: Sat, 10 Jan 2004 13:13:30 +0100
- Subject: Re: [tree-ssa] fold each statement
- References: <20040107221429.GB474@kam.mff.cuni.cz> <20040110030701.GA6724@redhat.com>
> On Wed, Jan 07, 2004 at 11:14:29PM +0100, Jan Hubicka wrote:
> > It can't be fully done in remove_useless_* because before SSA folding
> > we miss come string simplification;
> What do you mean by "ssa folding"? Certainly there are no calls to
> fold or fold_stmt from rewrite_into_ssa.
The string builtin folder in the fold_stmt walks SSA graph to get strlen
of operand. When program is not in SSA form these cases are missed.
> While I agree that it would be nice to do some builtin folding late
> in the game, after constant propagation and the like, I don't see
> what this has to do with this problem -- that of non-folded trees
> coming out of gimplification.
> Seems to me that we should fold during remove_useless_*, and then
> fold just the builtins once more after (perhaps) ccp.
CCP folds only statements it propagate into, but it is still possible to
have builtin that is foldable by walking SSA graph but none of it's
operand constant propagate, so with current design we have to do
fold_stmt call on each statement once in when the graph is in the SSA
Or we can add a guard for the folding so only builtin calls are
re-folded, but I don't this we want to maintain the invariant that only
builtin folding walks the graph.
Alternatively we can move the folding that walks SSA graph somewhere
else (I think reshaping pass shall take care of this)