On Sat, Mar 8, 2008 at 19:29, Zdenek Dvorak <[EMAIL PROTECTED]> 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.
