[Bug tree-optimization/50346] Function call foils VRP/jump-threading of redundant predicate on struct member

["scovich at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346

--- Comment #8 from Ryan Johnson <scovich at gmail dot com> 2012-03-07 14:28:29 UTC ---
(In reply to comment #7)
> On Wed, 7 Mar 2012, scovich at gmail dot com wrote:
> 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> > 
> > --- Comment #6 from Ryan Johnson <scovich at gmail dot com> 2012-03-07 13:31:19 UTC ---
> > (In reply to comment #5)
> > > On Wed, 12 Oct 2011, scovich at gmail dot com wrote:
> > > 
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50346
> > > > 
> > > > --- Comment #4 from Ryan Johnson <scovich at gmail dot com> 2011-10-12 12:40:25 UTC ---
> > > > (In reply to comment #3)
> > > > > Well, it's a tree optimization issue.  It's simple - the local aggregate f
> > > > > escapes the function via the member function call to baz:
> > > > > 
> > > > > <bb 5>:
> > > > >   foo::baz (&f);
> > > > > 
> > > > > and as our points-to analysis is not flow-sensitive for memory/calls this
> > > > > causes f to be clobbered by the call to bar
> > > > 
> > > > Is flow-sensitive analysis within single functions prohibitively expensive? All
> > > > the papers I can find talk about whole-program analysis, where it's very
> > > > expensive in both time and space; the best I could find (CGO'11 best paper)
> > > > gets it down to 20-30ms and 2-3MB per kLoC for up to ~300kLoC. 
> > > 
> > > It would need a complete rewrite, it isn't integratable into the current
> > > solver (which happens to be shared between IPA and non-IPA modes).
> > That makes sense...
> > 
> > Wild idea: would it be possible to annotate references as "escaped" or "not
> > escaped yet" ? Anything global or passed into the function would be marked as
> > escaped, while anything allocated locally would start out as not escaped;
> > assigning to an escaped location or passing to a function would mark it as
> > escaped if it wasn't already. The status could be determined in linear time
> > using local information only (= scalable), and would benefit strongly as
> > inlining (IPA or not) eliminates escape points.
> 
> Well, you can compute the clobber/use sets of individual function calls,
> IPA PTA computes a simple mod-ref analysis this way.  You can also
> annotate functions whether they make arguments escape or whether it
> reads from them or clobbers them.
> 
> The plan is to do some simple analysis and propagate that up the
> callgraph, similar to pure-const analysis.  The escape part could
> be integrated there.

That sounds really slick to have in general... but would it actually catch the
test case above? What you describe seems to depend on test() having information
about foo::baz() -- which it does not -- while analyzing the body of test()
could at least identify the part of f's lifetime where it cannot possibly have
escaped.

Or does the local analysis come "for free" once those IPA changes are in place?