similar to: TBAA for struct fields

[AMD Public Use] Hi Oliver, I get rid of the warnings by explicitly type-casting it to struct*, and still get similar results. ####################################################### struct P { float f1; float f2; float f3[3]; float f4; }; void foo(struct P* p1, struct P* p2) { p1->f2 = 1.2; p2->f1 = 3.7; } int callFoo() { struct P p; foo(&p,

Hey Matt, That's awesome. Thank you very much for all the information and clarification! Just a few follow up questions. Could you kindly shed some lights on it? Thank you! 1. I tried to tweak the code in the following way: - Clang [-> LLVM-IR]: https://llvm.godbolt.org/z/n9rGrs - [LLVM-IR ->] opt: https://llvm.godbolt.org/z/Uc6h5Y And i note that the outputs are: Alias sets for

Hello, I am performing alias analysis toward the following simple code: struct MyStruct { int * f1; int * f2; }; void NOALIAS(void* p, void* q){ } int main() { struct MyStruct s[2]; int a,b; s[0].f1 = &a; s[1].f1 = &b; NOALIAS(s[a].f1, s[b].f2); return 0; } When I use the following command to generate .bc code and conduct alias analysis: clang -c -emit-llvm t.c -O2 opt -basicaa

Hi all, I am trying to use LLVM's AliasAnalysis pass, but from a standalone tool that uses llvm libraries. The following is the code snippet I am currently using. PassBuilder PB; auto mod_manager = ModuleAnalysisManager { }; PB.registerModuleAnalyses(mod_manager); AAResults& AAR = mod_manager.getResult<AAManager>(*M); But the code fails at .getResult with the following error:

Oh. So it wasn't just the memory location size that was incorrect on those aliasing checks. I took a look at the tests and it appears that the alias call also catches some cases of restrict/noalias attributes, along with the tbaa info. My first idea of constructing an alias call with no Ptr's but valid tbaa info won't catch that at least. I will create a bug report and try and see if

Alias analysis is figuring out the relationship between two pointer expressions, at some location in the program. At a given point in the program, do two expressions always refer to the same location? At a given point in the program, do two expressions never refer to the same location? AliasAnalysis::alias() doesn't explicitly take a "point" in the program because we don't

Hi, I'm trying to get AA results for two pointers, but it seems that AA cannot look though a memcpy. For example: define dso_local spir_func void @fun() { entry: ; Store an address of `var' %var = alloca i32, align 4 store i32 42, i32* %var, align 4 %var.addr = alloca i32*, align 8 store i32* %var, i32** %var.addr, align 8 ; Memcpy

On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >> Hi, >> >> I'm trying to get AA results for two pointers, but it seems that AA >> cannot look though a memcpy. For example: >> >> define dso_local spir_func void @fun() { >> entry: >> ; Store an address of `var' >> %var = alloca i32, align 4 >>

Hi! On 7/10/2020 07:17, Shuai Wang wrote: > Hello! > > Thank you very much! Yes, that makes a lot of sense to me. However, just > want to point out two things that are still unclear: > > 1. The output contains a alias set of only one element, for instance: > "must alias, Mod       Pointers: (i32* %y, LocationSize::precise(4))" > > This one really confused

Hi Johannes, I followed your advice and got the same result: NoAlias and No dependence. Would you say AA is faulty for saying NoAlias or DA is faulty for saying no dependence? Or both? (revised example below) Thanks! define float @f() { entry: %g = alloca float, align 4 %h = alloca float, align 4 br label %for.body for.cond.cleanup: ; preds = %for.body

On 12/5/18 2:14 PM, Andrew Savonichev wrote: >> On 12/5/18 9:51 AM, Andrew Savonichev via llvm-dev wrote: >>>> Hi, >>>> >>>> I'm trying to get AA results for two pointers, but it seems that AA >>>> cannot look though a memcpy. For example: >>>> >>>> define dso_local spir_func void @fun() { >>>>

It seems the same bug is there if we do pointer swapping with selects. Do you agree? (see example below) define void @f() { entry: %a1 = alloca float, align 4 %a2 = alloca float, align 4 br label %loop end: ret void loop: %phi = phi i32 [ 0, %entry ], [ 1, %loop ] %select_cond = icmp eq i32 %phi, 0 %ptr1 = select i1 %select_cond, float* %a1, float* %a2 %ptr2 = select i1

Hi again! Replying in chronological order: > On Thu, Jul 9, 2020 at 6:51 PM Shuai Wang <wangshuai901 at gmail.com > <mailto:wangshuai901 at gmail.com>> wrote: > > Hey Matt, > > That's awesome. Thank you very much for all the information and > clarification! Just a few follow up questions. Could you kindly shed > some lights on it? Thank

Hello llvm-dev, I would appreciate your feedback on the following problem. We're trying to determine whether this is a bug in LLVM or not. In the IR snippet below, we have two pointers (p and q) which initially point to two completely non-overlapping locations. Then, on every iteration of a loop, we swap the pointers and load from the first, followed by a store to the second. 1) AA says the

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

There are function which does have optimization opportunities but because of may-alias memory dependencies sometimes optimization is not effective. May be runtime checks kills the gains of optimization. For such cases aiming to do interprocedural function specialization optimization where in the clone function version no-alias assumption can be assumed and the original function version will hold

On Tue, Dec 19, 2017 at 9:10 AM, Siddharth Bhat via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I could be entirely wrong, but from my understanding of memorySSA, each > def defines an "abstract heap state" which has the coarsest possible > definition - any write will be modelled as a "new heap state". > This is true for def-def relationships, but

Hi, Below is the snippet of LLVM IR code generated by Flang ---snip-- %3 = getelementptr i64, i64* %"a$sd", i64 11, !dbg !16 %4 = bitcast i64* %3 to i32*, !dbg !16 %5 = load i32, i32* %4, align 4, !dbg !16, !tbaa !22 ---snip-- My requirement is for any such LoadInst (example: %5), I want to check if its base GEP (i.e. %3) loads at particular offset (11) from its corresponding

1. I have a R program in a file say "functions.R". I load the "functions.R" file the R using source("function.R") and then call functionsf1(), f2() etc. which are declared and defined within "function.R" file. I also need to load a couple of R libraries using library() before I can use f1(), f2() etc. My question is can I acheive all this (i.e. calling

On 05/30/2018 06:04 AM, Siddharth Bhat via llvm-dev wrote: > You can run SCEV which will see through bitcasts and GEPs, so it > should give an expression of the form (base + offset) on the pointer > of the load. Specifically, you can use ScalarEvolution to subtract the expression for the base descriptor from the expression for the loaded pointer and see if the result is a SCEVConstant.