Re: Difference between {expand,fold,simplify}_builtin_foo ???

[Roger Sayle <roger at eyesopen dot com>]

On Mon, 20 Sep 2004, Jeffrey A Law wrote:
> > However what about fold_builtin_*?  Both fold_builin_* and
> > simplify_builtin_* return trees.  Are the fold_ variants allowed to
> > produce non-gimple?  Or are fold_builtin_* and simplify_builtin_*
> > really the same and we should canonicalize the naming convention?
> I didn't realize we had a 3rd routine.  Ugh.  I don't know which is
> preferred.  Sigh.

Hi Jeff and Kaveh,

My understanding/intention is that fold_builtin_foo is the preferred
tree folding interface, and it is allowed to generate non-gimple trees.
All the uses of simplify_builtin and fold_builtin in the middle-end and
tree-ssa have been converted to check whether their return values are
in gimple form and either ignore the result, or thanks to Jakub's recent
patch re-gimplify it.  The APIs to both fold_builtin and simplify_builtin
have been synchronized, such that as functionality is consolidated between
the two fold_builtin will eventually be a replacement for simplify_builtin
and all the simplify_builtin_foo forms can go away.

Generally, there should not be a need to call fold_builtin_foo (or
simplify_builtin_foo) from the RTL expanders such as expand_builtin_foo.
The RTL expansion should be able to rely on the tree being fully folded
prior to expansion, however, there may be some duplication of these
optimizations when the expand_builtin_* functions checks whether RTL
expansion has introduced an optimization opportunity, i.e. checking
whether expand_expr has return const0_rtx, where the fold form may have
checked for integer_zerop.


This duplication dates back to the branch for tree-ssa where in the
tree-ssa development tree the simplify_* forms of these functions were
added to enable optimizations during tree-ssa's DOM and CCP passes,
whilst on mainline the usual usual improvements/clean-ups in constant
folding resulted in fold_builtin with near identical functionality.
Originally on mainline fold was "destructive" and therefore unsuitable
for tree-ssa, and tree-ssa at that time could only handle gimple trees.
Once  the branch/mainline were merged this became needless duplication
and the effort of integrating the two schemes continued:

See http://gcc.gnu.org/ml/gcc-patches/2004-07/msg00312.html


Anyway, I hope this explains where things currently stand, or my
perspective of it.  Eric Christopher's patch looks exactly right :>


Roger
--