Hi,

I would like to announce that fold_buildN are now ready.

What's this?
------------

Put shortly, this is a tree equivalent of
simplify_build_{unary,binary,ternary}.  For example, we could replace

  fold (build2 (MULT_EXPR, type, op0, op1));

with

  fold_build2 (MULT_EXPR, type, op0, op1);

while avoiding a scratch node that build2 would create when folding is
possible.

What's so good about this?
--------------------------

Reduced memory usage.  Here is some quantitative justification for
this change:

  http://gcc.gnu.org/ml/gcc/2005-03/msg00277.html

It's my my turn to ask you a question
-------------------------------------

When and how do we want to do these conversion?

Currently, I am thinking about doing converting all of
"fold (buildN (...))" and "fold (build (...))" to fold_buildN as soon
as stage 2 starts, which is about one month away, so that I won't
annoy people as much.  I don't mind people starting to use fold_buildN
on new code or doing conversions on what they maintain, but I don't
think now is the right time to do the wholesale conversion.

Would you like fold_{unary,binary,ternary} exported?

These are equivalent to simplify_{unary,binary,ternary}.  They return
a folded tree if folding is possible.  Otherwise, they return
NULL_TREE.  If need arises, I am happy to export them for you.

Kazu Hirata

Reply via email to