This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Conversion from fold (buildN (...)) to fold_buildN.
- From: Kazu Hirata <kazu at cs dot umass dot edu>
- To: gcc at gcc dot gnu dot org
- Cc: mark at codesourcery dot com, roger at eyesopen dot com
- Date: Tue, 22 Mar 2005 12:38:34 -0500 (EST)
- Subject: Conversion from fold (buildN (...)) to fold_buildN.
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