[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