Hi, > On Sun, Mar 9, 2008 at 2:17 PM, Diego Novillo <[EMAIL PROTECTED]> wrote: > > On Sun, Mar 9, 2008 at 08:15, Richard Guenther > > <[EMAIL PROTECTED]> wrote: > > > > > What is GIMPLE_SINGLE_RHS after all? > > > > Represents a "copy" operation, an operand with no operator (e.g., a = 3, b > > = c) > > > > '3' and 'c' are "single" operands. There is no operator involved in > > the assignment. > > So as opposed to a unary operation which would look exactly the same apart > from having a subcode? So what does gimple_assign_subcode () return > for the GIMPLE_SINGLE_RHS case? Some random garbage?
just now, it will return the TREE_CODE of the rhs of the assignment (e.g. VAR_DECL and INTEGER_CST in the cases mentioned above). The problem we discuss in this thread is that actually the code is the TREE_CODE of rhs in the moment that the statement was built; so after ssa form creation, the gimple_assign_subcode of b_1 = c_2 will still be VAR_DECL; and after constant propagation of c_2 = 4, the gimple_assign_subcode of b_1 = 4 will still be VAR_DECL. While this is essentially harmless (only the fact that the code is in GIMPLE_SINGLE_RHS class is important for the semantics), it seems likely to cause some confusion, Zdenek
