Re: [tree-ssa] Inlining vs gimple vs compound expressions

[law at redhat dot com]

In message <1046375862 dot 29820 dot 352 dot camel at p4>, Andrew MacLeod writes:
 >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. 
OK.

[ ... ]
 >I thought this was a problem too, but apparently not.
 >
 >you could use the container....
Possibly, though it that may require some major surgery in the inliner
since it's not aware of containers at all.  It just DFS walks the
function's entire tree structure replacing suitable CALL_EXPRs with
BIND_EXPRs.

Assuming that surgery isn't insanely difficult we have to keep both
the old scheme and the new scheme around since someone could compile
with -fdisable-simple and inlining still needs to work.


 >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? :-)
I don't follow how this tells you if the call was on the LHS or RHS, but
for now I'll assume it does and start looking at what it would take to
make the inliner know about containers....

Jeff