Bug 23659 - Should able to add dereferencing (statements with VUSE) without rerunning may_alias
Summary: Should able to add dereferencing (statements with VUSE) without rerunning may...
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.1.0
: P2 enhancement
Target Milestone: ---
Assignee: Diego Novillo
URL:
Keywords: alias
Depends on:
Blocks: 23330
  Show dependency treegraph
 
Reported: 2005-08-31 16:59 UTC by Andrew Pinski
Modified: 2007-07-09 05:47 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2007-07-09 05:47:15


Attachments
Possible patch (4.82 KB, patch)
2006-03-01 12:10 UTC, Zdenek Dvorak
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Pinski 2005-08-31 16:59:58 UTC
An example of this comes from PR 18298:
extern "C" int strcmp (const char*, const char*);

char s[2048] = "a";

inline bool foo(const char *str) {
  return !strcmp(s,str);
}
int main() {
  while(!(foo(""))) {
    s[0] = '\0';
  }
  return 0;
}

In fab, we replace:
  #   VUSE <s_1>;
  D.1754_4 = strcmp (&s[0], &""[0]);

With   
  D.1777_6 = (const unsigned char *) &s[0];
  D.1778_9 = *D.1777_6;
  D.1779_3 = (int) D.1778_9;
  D.1754_4 = D.1779_3;

And the "  D.1778_9 = *D.1777_6;" statement does not have a VUSE which causes wrong code if we 
have a V_MAY_DEF/V_MUST_DEF above (which happens in the testcase).

The main reason why I am asking this question so that in the tree combiner, I don't want to rerun 
may_alias after each time I run the tree combiner which just becomes too expensive.

An example for the tree combiner would be:
int f(char *a)
{
  int b = strlen(a);
  return b == 0;
}
Comment 1 Steven Bosscher 2005-08-31 21:38:42 UTC
Can the alias gurus please give their view on this one? 
Comment 2 Diego Novillo 2005-08-31 21:41:35 UTC
Working on it.
Comment 3 Andrew Pinski 2005-11-12 05:32:17 UTC
This should remove the need to change may_alias to a TODO (PR 23330).
Comment 4 Zdenek Dvorak 2006-03-01 12:10:08 UTC
Created attachment 10944 [details]
Possible patch

(In reply to comment #2)
> Working on it.
> 

are you still working on this PR?

I think something similar to the attached patch should fix the problem -- it makes us remember alias class --> TMT mapping globally, and uses it to set up TMT's for the new pointers.  Could you please comment on whether you consider this the right approach, or propose an alternative one?

On a side note, things like this might become even more difficult with the new memory ssa approach.
Comment 5 Diego Novillo 2006-03-01 14:30:53 UTC
(In reply to comment #4)

> are you still working on this PR?
> 
Yes.  In fact, it's one of the kind of manipulations that drove the design decisions in memory SSA.

> I think something similar to the attached patch should fix the problem -- it
> makes us remember alias class --> TMT mapping globally, and uses it to set up
> TMT's for the new pointers.  Could you please comment on whether you consider
> this the right approach, or propose an alternative one?
> 
Whenever a new pointer symbol is introduced, it should receive a type tag.  This type tag is then assigned a set of aliases (or not, depending on context).  In fact, my plan is for these manually added type tags to be marked so that subsequent alias passes don't affect them.  This should help the vectorizer and other passes introduce a pointer symbol with a specific set of points-to aliases that the aliaser may not have a chance of compute so accurately otherwise.

> On a side note, things like this might become even more difficult with the new
> memory ssa approach.
> 
Huh.  What makes you think that?