Re: [tuples] gimple_assign_subcode for GIMPLE_SINGLE_RHS

[Diego Novillo <dnovillo at google dot com>]

On 3/9/08 3:24 PM, Zdenek Dvorak wrote:

> however, it would make things simpler.  Now, we need to distiguish
> three cases -- SINGLE, UNARY and BINARY; if we pretended that
> GIMPLE_COPY is an unary operator, this would be reduced just
> to UNARY and BINARY.  Of course, GIMPLE_COPY would never be used
> in a tree expression.

That's not the problem, the problem is in functions like 
extract_ops_from_tree.  Suppose that get_gimple_rhs_class returns 
GIMPLE_UNARY_RHS for SSA_NAME, we would then proceed to retrieve 
TREE_OPERAND (SSA_NAME, 0) for operand 1, which is wrong.

So, at some point we have to distinguish trees that are unary operators, 
which we want to flatten by extracting their operand, and trees that are 
to be used whole (like *_REF, SSA_NAME, *_DECL, CONST_*, etc). 
Particularly when optimizers use things like 
gimple_assign_set_rhs_from_tree.

Having said that, I think it may be possible to make this distinction 
internally in the low-level GIMPLE manipulators without exposing this to 
the optimizers.

I need to introduce GIMPLE_TERNARY_RHS (for ASSERT_EXPR) and 
GIMPLE_QUATERNARY_RHS (for COND_EXPR), so we will have at least four 
classes to deal with in the future.  I could add GIMPLE_COPY then, 
unless you want to work on it now.


Diego.