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 Sat, Mar 8, 2008 at 19:29, Zdenek Dvorak <> 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)


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.


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