This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Simplify/improve fold_Nary_to_constant
- From: Jeffrey A Law <law at redhat dot com>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 04 Apr 2005 11:12:54 -0600
- Subject: Re: [PATCH] Simplify/improve fold_Nary_to_constant
- Organization: Red Hat, Inc
- References: <Pine.LNX.4.44.0504031707050.14412-100000@www.eyesopen.com>
- Reply-to: law at redhat dot com
On Sun, 2005-04-03 at 19:13 -0600, Roger Sayle wrote:
> Now that Kazu has reorganized fold's internal APIs, its possible to
> trivially implement fold_binary_to_constant using fold_binary and
> fold_unary_to_constant using fold_unary. Using the obvious two line
> implementations of these functions, avoids creating the tree node
> that was the original motiviation for these routines, but also allows
> us to catch more optimizations and at the same time reduce the code
> duplication.
A correction. The original motivation was:
1. Avoid the overhead of the generic folder when all we wanted to do
was fold an expression down to a constant or do nothing. There was a
time when this overhead was easily measurable.
2. The old folder was destructive, which made it totally unsuitable
for use by CCP (where we need to know if an expression folds to a
constant, but we can not "commit" that change as a backedge in the
graph can cause one or more of the expression's operands to change
from a constant to a varying object).
I know we made a lot of changes to CCP a while back, which may (or may
not) reduce the number of folding attempts we make. It would probably
be worth doing some simple timing tests before/after your changes to
see if it has any compile time impact.
Avoiding creating of useless nodes happened as a side effect of how
we dealt with #2 -- namely, we didn't pass in the original expression
node, we pass in an operator and operands, thus we didn't have to
worry about the original node getting mucked up (though we did have
to be careful and not muck up the operands).
> Jeff, what do you think?
>
>
> 2005-04-03 Roger Sayle <roger@eyesopen.com>
>
> * fold-const.c (fold_relational_hi_lo): Delete function and prototype.
> (fold_binary): Update comment mentioning fold_relational_hi_lo.
> (fold_binary_to_constant): Simplify using fold_binary.
> (fold_unary_to_constant): Likewise, simplify using fold_unary.
If we're not taking a noticable compile-time hit, then I'm all for it.
jeff