[LLVMbugs] [Bug 11331] New: alias analysis problem in LICM

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=11331

             Bug #: 11331
           Summary: alias analysis problem in LICM
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ggan at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I met an alias analysis problem in LICM phase. I am using the following piece
of code to present this problem. You can compile it after removing the heading
line numbers. The compilation flag is "-O3 -funroll-loops"

     1 int size;
     2 int ** AAA;
     3 void * xalloc(int);
     4
     5 void foo(void)
     6 {
     7   int i;
     8   AAA = (int**) xalloc(size * sizeof(int*));
     9
    10   for (i=0; i<size; i++)
    11     AAA[i] = 0;
    12 }

This code tries to initialize an array of pointers. The array is allocated from
heap. "AAA" points to the beginning of the array and it is a global variable.

I got the following IR dump after LICM:

   82 *** IR Dump After Loop Invariant Code Motion ***
   83 for.body:                       ; preds = %for.body.lr.ph, %for.body
   84   %i.02 = phi i32 [ 0, %for.body.lr.ph ], [ %inc, %for.body ]
   85   %4 = load i32*** @AAA, align 4, !tbaa !3
   86   %arrayidx = getelementptr inbounds i32** %4, i32 %i.02
   87   store i32* null, i32** %arrayidx, align 4, !tbaa !3
   88   %inc = add nsw i32 %i.02, 1
   89   %cmp = icmp slt i32 %inc, %3
   90   br i1 %cmp, label %for.body, label %for.cond.for.end_crit_edge

I was expecting that line 85, i.e. "%4 = load i32*** @AAA", could be treated as
loop invariant code and be moved out of the loop body. However, it didn't. The
reason is that, LLVM thinks pointer "@AAA" would alias pointer "&AAA[i]". I
found GCC can move this load out of the loop body.

Then I went to read the current LLVM (v2.9) alias analysis code, i.e. BasicAA
and TBAA. I found that TBAA does not differentiate pointers. Any pointer will
be
given the same tbaa meta-data named "any pointer". After reading the TBAA code,
I believe that it is very difficult to solve my problem in the current TBAA
alias analysis framework. I'm expecting a better implementation of the alias
analysis algorithm in LLVM.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.