This is the mail archive of the gcc@gcc.gnu.org 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


Hi,

> >>So, what about adding a GIMPLE_COPY code?  The code would have 0
> >>operands and used only for its numeric value.
> >
> >another possibility would be to make GIMPLE_COPY an unary operator, and
> >get rid of the SINGLE_RHS case altogether (of course, unlike any other
> >unary operator, it would not require its operand to be gimple_val, so
> >special handling might still be necessary at some places. but it might
> >be less cumbersome),
> 
> Remember that GIMPLE_COPY *never* needs to be built as a tree node. 
> When gimplifying something MODIFY_EXPR <VAR_DECL<a>, CONST_INT> we do 
> not need to create a GIMPLE_COPY tree node.
> 
> We merely need to set the subcode for GIMPLE_ASSIGN to be GIMPLE_COPY:
> 
> GIMPLE_ASSIGN <GIMPLE_COPY, VAR_DECL<a>, CONST_INT>
> 
> So, making it a one operand operator is not really necessary.

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.

Zdenek


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