Take the following code: struct f { int i; int j; }; void g(void); void i(struct f*); int kk(void) { struct f a; int j; a.i = 1; a.j =2 ; g(); j = a.i; i(&a); return j; } --- j should be changed to 1 as the address of a is not escape until after the call to i so g should not get a call clobbered for the SFT's of a.
Confirmed.
*** Bug 26429 has been marked as a duplicate of this bug. ***
PR 18412 is not really a flow sensitive issue, it is just may_alias getting confused by pointer addition which will be fixed with the merge of the pointer plus branch.
*** Bug 59690 has been marked as a duplicate of this bug. ***
Note implementing a flow-sensitive ESCAPED set is not really possible within the current framework. Note that all memory operations are not flow-sensitive, so int *global; int kk(void) { int j; j = 1; g (); j += 2; global = &j; } will still cause g() to clobber j as far as points-to analysis is concerned (the write to 'global' is not flow-sensitive). "Trivial" optimization can avoid refering to ESCAPED in the first basic-block as long as nothing could have been possibly escaped yet. But that's a hack.
(In reply to Richard Biener from comment #5) Would it be possible to compute ESCAPED per basic block as a local set, compute transitive closure over the CFG, and use that information when constructing the points-to graph?
On Tue, 7 Jan 2014, steven at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23384 > > --- Comment #6 from Steven Bosscher <steven at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #5) > > Would it be possible to compute ESCAPED per basic block as a local set, > compute transitive closure over the CFG, and use that information when > constructing the points-to graph? Well, ESCAPED is computed by solving the points-to graph ... also "transitive closing" over the CFG isn't easily possible without doing a full points-to graph solving. I think more flow-sensitivity asks for a entirely different algorithm (or - just a weird quick idea - marking constraints with a "flow" version, and during solving only consider "older" edges/constraints and only when that converged bump the "age" of the solving process. that's probably equivalent to incrementally building / solving the points-to graph for all SESE regions in a dominator order)
*** Bug 81788 has been marked as a duplicate of this bug. ***
As a data point, Clang manages to optimize at least the simple case in bug 81788 as expected. No other compiler I've tested does (IBM XLC, Intel ICC, Visual Studio, or Sun/Oracle Studio).
*** Bug 108217 has been marked as a duplicate of this bug. ***