[tree-ssa] Inlining vs gimple vs compound expressions

[Andrew MacLeod]

On Thu, 2003-02-27 at 14:46, law@redhat.com wrote:
> 
> 
> Diego/Andrew -- Back when we were in Toronto, we discussed getting rid of
> COMPOUND_EXPRs.  Where do we stand on this?
> 

As far as I know, they are going to be around for a little while. I
beelive its a quite invasive change to the front ends to generate tree's
diofferently. Im supplying some generic link routines which the fornt
ends can then be modified to use, and then once they use nothing but
those routines, we can plug in another solution. 

> 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
> 
> 
Dunno, but I don't see why not.

> 
> 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
> 
>
Yes, I beleive the last CE node has 2 statements.. ie, the last CE node
will always look like this. Thats my understanding anyway.

 
>              
> 
> 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.
> 

I thought this was a problem too, but apparently not.

you could use the container....  thats how we do it in other places.
So instead of pushing on the CE node, you push on the address of the
field which points to the CE node. Then, when you pop it off, you
dereference it, and you are going to be looking at either
  - a CE node, in which case its a container, and you now its on the
LHS, or
  - something other than a CE node, which means its the RHS of a CE.

And since you have the address of the pointer to this node, you can
easily add new CE nodes, or do whatever you want.

Is that too cryptic? :-)

Andrew