Re: [tuples] gimple_assign_subcode for GIMPLE_SINGLE_RHS

["Diego Novillo" <dnovillo at google dot com>]

On Sat, Mar 8, 2008 at 19:29, Zdenek Dvorak <rakdver@kam.mff.cuni.cz> wrote:

>  The problem of course is that for GIMPLE_SINGLE_RHS, we do not maintain
>  the invariant that
>
>  gimple_assign_subcode (stmt) == TREE_CODE (gimple_assign_rhs1 (stmt)),
>
>  so gimple_assign_subcode typically will not be SSA_NAME, but VAR_DECL.
>  Enforcing this invariant might be hard and probably asking for more
>  trouble than it is worth.  However, perhaps it would make sense
>  to use some special tree code to indicate GIMPLE_SINGLE_RHS, in order
>  to avoid confusion?

Hmm, yeah.  I remember talking about this with Bill a few days ago.
He had a similar idea.

At the time I was a bit reluctant to add a new tree code just for
this, but now you've run into it and I was also looking at some code
that would run into the same problem.  Now I agree that adding a new
tree code will be the cleanest way.  We will be removing several tree
codes when tuple merges, so the net result in tree.def will be a
reduction of tree codes.

In this case, the renamer was at fault.  When it replaced the USE
operand with an SSA_NAME it failed to change the subcode.

The other problem with not using a special code for GIMPLE_SINGLE_RHS
is confusion

a_3 = b_5

is (if we fixed the renamer bug)

GIMPLE_ASSIGN <SSA_NAME, SSA_NAME<a_3>, SSA_NAME <b_5>>

So, the subcode seems to duplicate the code on the RHS.  That looks odd.

So, what about adding a GIMPLE_COPY code?  The code would have 0
operands and used only for its numeric value.


Diego.