[PATCH] Split simplify_unary_operation and simplify_binary_operation
Roger Sayle
roger@eyesopen.com
Sat Feb 12 15:46:00 GMT 2005
On Fri, 11 Feb 2005, Eric Christopher wrote:
> > 2005-02-10 Paolo Bonzini <bonzini@gnu.org>
> >
> > * simplify-rtx.c (simplify_unary_operation_1): Extract from...
> > (simplify_unary_operation): ... this one.
> > (simplify_binary_operation_1): Extract from...
> > (simplify_binary_operation): ... this one.
>
> Maybe you could split the individual functions out more? They're still
> huge monolithic functions. Just opinion, can't approve it either way.
My apologies to Paolo for getting distracted before commenting on his
patch.
As you wrote in your post:
> > All of the simplifications that simplify_relational_operation can do
> > and that do not depend on the operations being constants are in a
> > separate function, simplify_relational_operation_1.
I think your patch might benefit from following the role model of
simplify_relational_operation even closer. As you describe, this
function is split along the constant operands/non-constant operands
divide as you propose in your patch. However, rather than just
break-out the non-constant bits, it also creates a subroutine for
the constant bits. The function simplify_const_relational_operation
ends up being useful in its own right, and can potentially be used
by other RTL optimizers when its known both operands are constant.
Along these lines, a more aggressive version of your patch could introduce
simplify_const_unary_operation and simplify_const_binary_operation,
which themselves (unlike simplify_foo_operation_1) might have utility
outside of simplify-rtx.c. Indeed, there are probably several callers
of simplify_binary_operation that could be replaced with direct calls
to simplify_const_binary_operation.
Sound reasonable?
Roger
--
More information about the Gcc-patches
mailing list