Re: PATCH: RTL_EXPR vs. inlining-on-trees

[kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)]

    The function returns that pointer, not the structure value itself.
    Hence, the temporary is not preserved.

It should be.  This sort of thing is quite common in Ada too.
That's what mark_temp_addr_taken is for.

    Again, this points out what I consider to be a missing feature in GCC:
    a stack-slot allocator that could operate much later in the game.
    It's silly to tie down the stack-slot shape as we expand statements;
    if those statements are, for example, dead, we're committed to
    stack-slots we don't want.

I most certainly agree.  I've been trying for years to figure out a good
way to do that, but the problem is that the computations to address these
stack slots themselves are things that need to be cse'ed and moved out
of loops, so you can't do it too early either.

    The question is this: can you imagine legitimate uses of an RTL_EXPR,
    where the temporaries have a longer lifetime?  And the answer, of
    course, is yes.  You might want to generate a little bit of RTL to
    create a few variables, initialize them, and then use the whole thing
    somewhere else.

With those variable *inside* or *outside* of the RTL_EXPR?

    I've adopted the solution I rejected in my previous posting: to add a
    flag to RTL_EXPRs.

But when that flag is set, what about temporaries allocated by the
backend which were inside a push/pop?  Those will simply be mishandled
and will overlap memory that was allocated to something else if the
RTL_EXPR is moved.  

This can't be done with a bit in RTL_EXPR, but has to be done by doing
something different with the way those special variables are allocated: you
have to move them up in temporary level.