Bug 23384 - escaped set should be flow sensitive
escaped set should be flow sensitive
Status: NEW
Product: gcc
Classification: Unclassified
Component: tree-optimization
4.1.0
: P2 enhancement
: ---
Assigned To: Not yet assigned to anyone
: alias, missed-optimization
: 26429 59690 (view as bug list)
Depends on:
Blocks: 21093
  Show dependency treegraph
 
Reported: 2005-08-14 06:17 UTC by Andrew Pinski
Modified: 2014-01-08 08:58 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-01-06 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-08-14 06:17:14 UTC
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.
Comment 1 Andrew Pinski 2005-08-31 16:03:31 UTC
Confirmed.
Comment 2 Andrew Pinski 2006-02-22 23:04:17 UTC
*** Bug 26429 has been marked as a duplicate of this bug. ***
Comment 3 Andrew Pinski 2007-05-22 01:38:02 UTC
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.
Comment 4 Andrew Pinski 2014-01-05 23:14:53 UTC
*** Bug 59690 has been marked as a duplicate of this bug. ***
Comment 5 Richard Biener 2014-01-07 11:26:49 UTC
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.
Comment 6 Steven Bosscher 2014-01-07 22:46:21 UTC
(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?
Comment 7 rguenther@suse.de 2014-01-08 08:58:17 UTC
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)