This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [RFC] fold Reorganization Plan
- From: Nathan Sidwell <nathan at codesourcery dot com>
- To: Kazu Hirata <kazu at cs dot umass dot edu>
- Cc: gcc at gcc dot gnu dot org, dvorakz at suse dot cz, roger at eyesopen dot com
- Date: Sat, 12 Feb 2005 13:43:51 +0000
- Subject: Re: [RFC] fold Reorganization Plan
- Organization: CodeSourcery LLC
- References: <20050212.000649.74746665.kazu@cs.umass.edu>
Kazu Hirata wrote:
I am planning to reorganize fold as suggested by Roger Sayle on IRC.
good for you! reorganizing fold is an excellent idea.
The shortest way to describe this mini project would be to develop the
tree equivalent of simplify_gen_ARITY and simplify_ARITY in the RTL
world. Doing so should reduce the number of scratch tree nodes
created when idioms like fold (buildN (...)) are used. Hopefully, we
should be able to pick up some compile-time improvement along the way.
By the way, the past proposals from Roger Sayle are found at:
http://gcc.gnu.org/ml/gcc-patches/2003-10/msg01514.html
http://gcc.gnu.org/ml/gcc/2004-01/msg00560.html
Both of these are along the same lines as above.
Any comments?
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,
1) evaluation of constant expressions, where the language requires a compile
time constant value. Such values should be calculated lazily by some
language specific function (possibly using common backend functions). This
would produce an error or an appropriate _CST node.
2) A common occurrence is such things as fold (build (PLUS_EXPR, a, b)),
where it is known that a and b are _CST nodes. This kind of thing happens
in array initialization and vtable construction, and probably several
other bookkeeping tasks. Here the operation is virtually always one
of ADD, SUB, MUL and the types are integral types. Here we should
have an interface that ONLY deals with those three operations and ONLY
deals with already-coerced integral types. Whether we have separate
eval_integral_OP (a, b) functions or eval_integral (OP, a, b), I don't
know.
nathan
%-I guess gimplifying unfolded expressions might lead to an explosion of
statements. It might be prudent to apply folding during the gimplification
phase as well. If the SSA folding pass has the correct interface, I'd hope
it can be applied to gimple statements and pre-gimplified trees.
--
Nathan Sidwell :: http://www.codesourcery.com :: CodeSourcery LLC
nathan@codesourcery.com :: http://www.planetfall.pwp.blueyonder.co.uk