Re: [tree-ssa] live analysis on local static functions

[law at redhat dot com]

In message <20031014175959.GB27685@redhat.com>, Richard Henderson writes:
 >On Tue, Oct 14, 2003 at 01:47:20PM -0400, Andrew MacLeod wrote:
 >> nope. both are 0. Oh wait, yeah. the one in the BIND_EXPR does ($7). It
 >> points to the one we are using in a_1. (the $9 value)
 >
 >So there's a bug in inlining somewhere.  One of the following
 >must be true:
 >
 >  (1) All inline function instances share the same local statics,
 >      and so remapping the value in the BIND_EXPR is wrong, or
 >  (2) All inline function instances have their own instances of
 >      local statics and so not remapping the value in the body of
 >      the function is wrong (which leads to the a_1 use).
 >
 >I seem to recall that (1) is correct, since that doesn't change
 >semantics depending on how inlining does or does not occur.
Hmmm, yea, I think I remember discussing this in the deep dark past.  And
I think we agreed that (1) is correct (though I also think we decided that
we can't guarantee absolute no semantic changes in an inline function).

 >I can see that something must be done for debugging, since you
 >want to refer back to the origin from the inlined instance.  No
 >idea how this interacts with the rest of the code...
I suspect (but certainly haven't confirmed) that the variable inside
the BIND_EXPR is mostly ignored.  When we do look at it, I suspect we
actually look through to the version in the original function to preserve
semantics.

I could do the same in the useless variable remover, but before doing
so we probably should verify whether or not the remapping in the BIND_EXPR
is valid or not (and that's an area I certainly don't know all that well).

jeff