This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tuples] gimple_assign_subcode for GIMPLE_SINGLE_RHS

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]