[cfe-dev] [LLVMdev] For alias analysis, It's gcc too aggressive or LLVM need to improve?

[Daniel Berlin]

On Mon, Aug 11, 2014 at 11:44 PM, Kevin Qin <kevinqindev at gmail.com> wrote:

> Hi all,
>
> Thanks for you paying time to look at this issue. I'm not an expert for
> C/C++ language, so I can just post some experiment results from LLVM and
> GCC.
>
> If we make minor changes to the test, gcc may give different results.
>
> #include <stdio.h>
> struct heap {int index; int b;};
> struct heap **ptr;
> int aa;
>
> int main() {
>   struct heap element;
>   struct heap *array[2];
>   array[0] = (struct heap *)&aa;
>   array[1] = &element;
>   ptr = array;
>   aa = 1;
>   int i;
>   for (i =0; i< 2; i++) {
>     printf("i is %d, aa is %d\n", i, aa);
>     array[i]->index = 0;  // we replace ptr to array here. so no global
> lvalue is used.
>   }
>   return 0;
> }
>
> Result didn't get changed,
>
> $gcc test.c -O0
> $./a.out
> i is 0, aa is 1
> i is 1, aa is 0
>
> $gcc test.c -O2
> $./a.out
> i is 0, aa is 1
> i is 1, aa is 1
>
> But if we change a bit more, like
>
> #include <stdio.h>
> struct heap {int index; int b;};
> struct heap **ptr;
> int aa;
>
> int main() {
>   struct heap element;
>   struct heap *array[2];
>   array[0] = (struct heap *)&aa;
>   array[1] = &element;
>   //ptr = array; // remove this assignment as well.
>   aa = 1;
>   int i;
>   for (i =0; i< 2; i++) {
>     printf("i is %d, aa is %d\n", i, aa);
>     array[i]->index = 0;  // we replace ptr to array here. so no global
> lvalue is used.
>   }
>   return 0;
> }
>
> Result changed to be the same as LLVM.
>
> $gcc test.c -O0
> $./a.out
> i is 0, aa is 1
> i is 1, aa is 0
>
> $gcc test.c -O2
> $./a.out
> i is 0, aa is 1
> i is 1, aa is 0
>
> I don't know why a assignement statment to a unrelated global pointer will
> affect gcc's aliasing work,
>

Because it blocks the load elimination/copy propagation.  With that pointer
assignment there, GCC sees it as a global aliasing the same memory location
as the array, and that global escapes the function.  Because of that, it no
longer believes it knows what happens to the memory once the printf call
happens (since it's really a call to printf_chk, and because of the way
glibc works, printf is not a readonly functiojn)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140812/ac536597/attachment.html>