[llvm-dev] Alias analysis only throwing mayAlias for something that seems should be identifiable as mustAlias

Finkel, Hal J. via llvm-dev llvm-dev at lists.llvm.org
Sat Nov 9 01:40:04 PST 2019


Hi, Kiwan,

What sizes are you passing to AA when you make the query (i.e., how are you constructing the MemoryLocation)? I would expect an access to the eighth element and the first element to be NoAlias, although maybe MayAlias if something is confusing the analysis.

 -Hal

On 11/5/19 6:05 PM, 맹기완 via llvm-dev wrote:
I have a global 2-D array ARRAY[N][M] and I am accessing it inside the for loop like this:

for (i...)
  for (j ...)
    ARRAY[i][j] ...

So nothing really weird is happening. If I look at the generated IR, it is also fairly straight forward.

@ARRAY0 = dso_local global [32 x [32 x i32]] zeroinitializer, section ".slow_mem", align 32, !dbg !84
...
%45 = getelementptr inbounds [32 x [32 x i32]], [32 x [32 x i32]]* @ARRAY0, i32 0, i32 %22, i32 7, !dbg !180
store volatile i32 %43, i32* %45, align 4, !dbg !181, !tbaa !148

As you can see, the GEPInst exactly knows it is the ARRAY0, and it knows statically that it is accessing the 7th element.
However, when I try to call alias analysis in the LLVM pass, as in

AliasAnalysis *AA = ...
AA->alias(a, b)

where a is the ARRAY0 global variable and b is the GEPInst (%45), I only get mayAlias.
When reading the basicaa description, it seems like it should know that the two is must alias. What am I missing?

I did not know how I should post code in the thread, so I apologize for the messy format.
Thank you,
Best Regards,
Kiwan



_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev


--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20191109/4a1a4a83/attachment.html>


More information about the llvm-dev mailing list