[Bug rtl-optimization/20367] alias analysis doesn't take into account that variables that haven't their address taken can't alias arbitrary MEMs

[amylaar at gcc dot gnu dot org]

------- Additional Comments From amylaar at gcc dot gnu dot org  2005-03-07 
20:27 -------
Here is an example out of the google cache:
http://66.102.9.104/search?q=cache:BGnyHfyQlSYJ:gcc.gnu.org/ml/gcc-patches/2004-02/msg01638.html+unspecified_indirect_ref_node&hl=en

RFA: alias analysis for non-addressed variables vs. INDIRECT_REF

    * From: Joern Rennecke <joern dot rennecke at superh dot com>
    * To: gcc-patches at gcc dot gnu dot org
    * Date: Wed, 18 Feb 2004 18:24:58 +0000 (GMT)
    * Subject: RFA: alias analysis for non-addressed variables vs. INDIRECT_REF

As discussed before, we are currently missing opportunities to
hoist out accesses of non-addressed variables.  I have now
modified my patch so that a special node unspecified_indirect_ref_node
is used in MEM_EXPRs to mark memory accesses that are generated
from an otherwise unspecified INDIRECT_REF.

Consider this test case:

int
f(int s, int *a)
{
  static int i;
  for (i = 0; i < 800; i++)
    s += a[i];
  return s;
}

For the inner loop, this is the code that I get for sh-elf at -O2 -m4
with mainline from 2004-02-17 without my patch:

.L5:
        mov.l   @r7,r1
        mov     r1,r0
        shll2   r0
        mov.l   @(r0,r5),r2
        add     #1,r1
        cmp/gt  r6,r1
        mov.l   r1,@r7
        bf/s    .L5
        add     r2,r3

And this with the patch; the loads and stores if the loop induction
variable 'i' (@r7) have been hoisted out, and the a[i] giv has been
strength reduced from @(r0,r5) to @r5+.

.L5:
        mov.l   @r5+,r1
        add     #1,r2
        cmp/gt  r3,r2
        bf/s    .L5
        add     r1,r0



-- 


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