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]

[tree-ssa] Inlining vs gimple vs compound expressions



Diego/Andrew -- Back when we were in Toronto, we discussed getting rid of
COMPOUND_EXPRs.  Where do we stand on this?

The reason I ask is I'm sitting here looking at how to modify the inliner
so that the trees it creates are still in gimple form.  And, believe it
or not, it doesn't look terribly hard.  Conceptually, all I think I need
is a stack of CE nodes.  Of course if CE nodes are going away soon,
then, well, my scheme would be a waste of time to implement.

If CE nodes are going to hang around for a little while, I've got a
couple of questions.

First, can we ever get a function with no CE nodes?  ie, can a function's
tree ever be something like this:

  RETURN_EXPR
      |
  MODIFY_EXPR
      /\
     /  \
    /    \
 RESULT CALL_EXPR



Second, is TREE_OPERAND (CE_NODE, 1)) ever anything other than another
CE node or NULL?  ie, is this a valid tree?

      CE
      /\
     /  \
    /    \
LOOP_EXPR \
        RETURN_EXPR
           |
        MODIFY_EXPR
           /\
          /  \
         /    \
      RESULT  CALL_EXPR


             

Or should it instead be:


      CE
      /\
     /  \
    /    \
LOOP_EXPR \
          CE
          /\
         /  \
        /    \
     RETURN  NULL
       |
     MODIFY
      /\
     /  \
    /    \
RESULT  CALL

The second form is easier to deal with as we always know the CALL is on 
the LHS of the CE at the top of the stack.  It also simplifies insertion
of the new CE node when we inline the call.


Jeff



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