similar to: Dependence Analysis bug or undefined behavior?

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

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

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

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

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

To avoid going too off-topic on the multidimensional gep thread, I'm asking this in a separate thread. >> I took a look earlier and didn't notice any target-independent ones that would need a separate type parameter Do you know what would happen with the llvm.ptr.annotation intrinsic? Frontends use that to annotate members of structs: struct S { [[some_annotation]] int

Hello, (fairly new around here, apologies if the question has an obvious answer) I've been studying the structure of the new PassManager in the hopes of using it soon. After watching a couple of talks (Chandler / Sergeev), I decided to start with the Concept/Model classes in PassManagerInternal.h While I could make sense of almost everything there, two details caught my attention: 1- The

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Arnamoy Bhattacharyya > Subject: [LLVMdev] Is Loop Dependence Analysis Printing Correct Stats? > for(i = 0; i < 4; i ++) > { > a[i] = a[i-1]+1; > } > Am I doing anything wrong or the code seems buggy? Your code is buggy. The first time through the loop, you're referencing

Hi; I was playing with the -lda pass of LLVM on the following program- #include <stdio.h> void main() { int a[10]; int i; for(i = 0; i < 4; i ++) { a[i] = a[i-1]+1; } } I run the following commands - clang a.c -emit-llvm -S opt -analyze -stats -lda a.s The output is - Printing analysis 'Loop Dependence Analysis': Loop at depth 1, header block: %for.cond Load/store

Hi , The following loop fails to be vectorized since the load c[i] is casted as i64 and the store c[i] is double. The loop access analysis gives up since they are in different types. Since these two memory operations are in the same size, I believe the loop access analysis should return forward dependence and thus the loop can be vectorized. Any comments? Thanks, Jin #define N 1000 double

Hi Arnold, Thanks for your reply. I tried test case as suggested by you. *void foo(int *a, int *sum) {*sum = a[0]+a[1]+a[2]+a[3]+a[4]+a[5]+a[6]+a[7]+a[8]+a[9]+a[10]+a[11]+a[12]+a[13]+a[14]+a[15];}* so that it has a 'store' in its IR. *IR before vectorization :*target datalayout = "e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128" target triple =

Hi Devs, I am looking at the bug https://bugs.llvm.org/show_bug.cgi?id=43953 and found that following piece of ir %arrayidx = getelementptr inbounds float, float* %Vec0, i64 %idxprom %0 = load float, float* %arrayidx, align 4, !tbaa !2 %arrayidx2 = getelementptr inbounds float, float* %Vec1, i64 %idxprom %1 = load float, float* %arrayidx2, align 4, !tbaa !2 %sub = fsub fast float %0, %1

Hi Suyog, Thanks for looking at this. This has recently got itself onto my TODO list too. > I am not sure how much all this will improve the code quality for horizontal reduction > (donno how frequently such pattern of horizontal reduction from same array occurs in real world/SPECS). Actually the main loop of 470.lbm can be SLP vectorized like this. We have three parts to it: A fully

Hello All, I have met one may-alias case from llvm's alias analysis. The code snippet is as following: char buf[4]; void test (int idx) { char *a = &buf[3 - idx]; char *b = &buf[idx]; *a = 1; *b = 2; } I can see below output from alias set tracker for above code snippet. Alias sets for function 'test': Alias Set Tracker: 1 alias sets for 2 pointer values.  

Hi, I am trying to get the alias info for the following code. The alias analysis returns "MayAlias" for arrays "A" and "B" in both the functions instead of "NoAlias". What passes should I run in opt before the alias analysis pass to get the accurate result? Example: //Note: static and called by func() only. static int sum(int *A, int *B) { int i = 0,

Hi Andrew, The issue below refers to LSR, so I'll appreciate your feedback. It also refers to instruction combining and might impact backends other than X86, so if you know of others that might be interested you are more than welcome to add them. Thanks, Anat _____________________________________________ From: Shemer, Anat Sent: Tuesday, February 18, 2014 15:07 To: 'llvmdev at

Hi, LLVM community: I found basicaa seems not to tell must-not-alias for __restrict__ arguments in c/c++. It only compares two pointers and the underlying objects they point to. I wonder how clang does alias analysis for c/c++ keyword restrict. let assume we compile the following code: $cat myalias.cc float foo(float * __restrict__ v0, float * __restrict__ v1, float * __restrict__ v2, float *

BTW, I have found why it doesn't work for arrays. TBAA information propagation is not implemented in CodeGenFunction::EmitArraySubscriptExpr with "TODO: Preserve/extend path TBAA metadata?". On Fri, Dec 4, 2015 at 1:38 PM, Dmitry Polukhin <dmitry.polukhin at gmail.com> wrote: > As far as I can see it is specifics of arrays inside structs. Current TBAA > does distinguish

Hi, Look at the following code: Look at the following C code seqence: unsigned char mainGtU ( unsigned int i1, unsigned int i2, unsigned char* block) { unsigned char c1, c2; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; c1 = block[i1]; c2 = block[i2]; if (c1 != c2) return (c1 > c2); i1++; i2++; .. ..

Jeroen, thank you for very useful link with the context. Indeed union cases are very complicated and I see places in code when TBAA gives up. Daniel, I completely agree that TBAA has limited power and can solve relatively simple cases only. So anything more complicated that involves intermediate variables that points to struct or array elements cannot be solved by TBAA alone. Differentiating