[tree-ssa] Inlining vs gimple vs compound expressions

[Andrew Haley <aph at redhat dot com>]

law at redhat dot com writes:
 > 
 > 
 > 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

I think I have seen that with Java.

 > 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

Java again: AFAIK in all cases it's quite legal to replace a
COMPOUND_EXPR with a BLOCK or a variable and vice versa.

Andrew.