User account creation filtered due to spam.

Bug 35358 - Ansi aliasing info not fully utilized by tree SSA optimizations
Summary: Ansi aliasing info not fully utilized by tree SSA optimizations
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.3.0
: P3 enhancement
Target Milestone: 4.5.0
Assignee: Not yet assigned to anyone
Keywords: alias, missed-optimization
Depends on: 35360
  Show dependency treegraph
Reported: 2008-02-25 05:07 UTC by davidxl
Modified: 2009-04-03 12:30 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2008-03-14 21:27:15


Note You need to log in before you can comment on or make changes to this bug.
Description davidxl 2008-02-25 05:07:09 UTC
// David Li

The issue is known and being worked on. File this bug report just to track the problem.

One of the rules that can be derived from the basic rules is that if two access's base types are the same, access offset and size can be used to determine the overlapping relationships of the two accesses. This is currently not handled in GCC -- most likely an implementation issue.

Example 38:

struct BUF1
  int b1;
  int b12;

int foo(int n, struct BUF1* p, struct BUF1* q)
    int i = 0;
    for (i = 0; i < n; i++)
        p->b1 += q->b12;            // Two accesses are not aliased with strict aliasing
    return 0;

The loop should be transformed into:

t1 = p->b1;
t2 = q->b12;
for (...)
  t1 += t2;
p->b1= t1;

The ansi rule can also be extended to handle cases where one type is nested within another one.

Example 39:

struct BUF1
  int b1;
  int b12;

struct BUF2
  int b2;
  int g;
  struct BUF1 bf1;

int foo(int n, struct BUF1* p, struct BUF2* q)
    int i = 0;
    for (i = 0; i < n; i++)
        p->b1 += q->b2;
    return 0;
Comment 1 Richard Biener 2008-02-25 11:47:23 UTC
Similar to the missing base/offset bug, PR35360.
Comment 2 Andrew Pinski 2008-02-25 18:21:13 UTC
Related to PR 13761 also.
Comment 3 Richard Biener 2008-03-14 21:27:15 UTC
Zdeneks lim/store-motion rewrite should fix this.
Comment 4 Andrew Pinski 2008-09-16 00:18:35 UTC
We get now:
<bb 4>:
  prephitmp.14 = prephitmp.14 + q->b2;
  p->b1 = prephitmp.14;
  i = i + 1;
  if (n > i)
    goto <bb 4>;
    goto <bb 5>;

Which means PRE has the right information but LIM does not ...
Comment 5 Richard Biener 2009-04-03 12:30:52 UTC
Both testcases are now fixed on trunk.  The first testcase is fixed for 4.4
as well.