This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
[tree-ssa] Inlining vs gimple vs compound expressions
- From: law at redhat dot com
- To: dnovillo at redhat dot com, amacleod at redhat dot com
- Cc: jason at redhat dot com, gcc at gcc dot gnu dot org
- Date: Thu, 27 Feb 2003 12:46:29 -0700
- Subject: [tree-ssa] Inlining vs gimple vs compound expressions
- Reply-to: law at redhat dot com
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