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

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

    Yes, but consider this:
    
      S f() { return S(); }
      S g() { return f(); }
      void h () { S s = g (); }

    Since we actually return structures by passing a pointer to a spot
    created in the caller, `g' creates a temporary.  In C++, we cleverly
    use TARGET_EXPRs to avoid extra copies, so given this situation we
    create only one temoprary; there is no additional temporary created in
    `h'.  So, if the `g' temporary is destroyed by the time we get back to
    `h', we're in trouble.

Right, but that's what the preserve calls are all about!  You have this
same thing when a C block expressions returns a BLKmode object.

    Yes -- in general, concepts in programs should serve one function. (*)
    RTL_EXPRs, as documented are:

      /* Represents something whose RTL has already been expanded
         as a sequence which should be emitted when this expression is
         expanded.  The first operand is the RTL to emit.  It is the first
         of a chain of insns.  The second is the RTL expression for the
         result.  */
  
    That's clear, coherent, and simple.  There's nothing in there about
    providing an implicit scope.  

No, but I'd argue that it's implicit in that definition: if you create any
temporaries within the expressions being expanded, they are "part" of
the RTL_EXPR.

    However, it seems that you could also arrange simply to have the
    front-end call push_temp_slots and pop_temp_slots before and after
    creating the RTL expression.  

No, that doesn't work *at all*!  The whole point of RTL_EXPR is to put
the code *somewhere else*.