similar to: Question about a May-alias case

Hi Eli, Thanks for good comment! I missed to initalize the buf. Let's slightly change the example as below. char subbuf1[2]; char subbuf2[2]; char subbuf3[2]; char subbuf4[2]; char *buf[4] = {subbuf1, subbuf2, subbuf3, subbuf4}; char c; void test(int idx) { char *a = buf[3 - idx]; char *b = buf[idx]; *a = *b; c++; *a = *b; } I think we can say the 'buf' does not

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++; .. ..

Verifying function running passes ... LV: Checking a loop in "bar" LV: Found a loop: L0 LV: Found an induction variable. LV: We need to do 0 pointer comparisons. LV: Checking memory dependencies LV: Bad stride - Not an AddRecExpr pointer %13 = getelementptr float* %arg2, i32 %1 SCEV: ((4 * (sext i32 {(256 + %arg0),+,1}<nw><%L0> to i64)) + %arg2) LV: Src Scev: {((4 * (sext

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.  

Frank, It looks like the loop vectorizer is unable to tell that the two stores in your code never overlap. This is probably because of the sign-extend in your code. Can you extend the indices to 64bit ? Thanks, Nadav On Oct 28, 2013, at 1:38 PM, Frank Winter <fwinter at jlab.org> wrote: > Verifying function > running passes ... > LV: Checking a loop in "bar" > LV:

On 06/11/2018 02:33 PM, Friedman, Eli via llvm-dev wrote: > On 6/11/2018 10:06 AM, jingu at codeplay.com via llvm-dev wrote: >> 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 =

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 *

Hi, Your problem is that the function arguments, which are makes as noalias, are not being directly used as the base objects of the array accesses: > %v0.addr = alloca float*, align 8 > %v1.addr = alloca float*, align 8 > %v2.addr = alloca float*, align 8 > %t.addr = alloca float*, align 8 ... > store float* %v0, float** %v0.addr, align 8 > store float* %v1, float** %v1.addr,

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 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, 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 all, One of the reasons the Livermore Loops couldn't be vectorized is that it was using global structures to hold the arrays. Today, I'm investigating why is that so and how to fix it. My investigation brought me to LoopVectorizationLegality::canVectorizeMemory(): if (WriteObjects.count(*it)) { DEBUG(dbgs() << "LV: Found a possible read/write reorder:"

Hi Daniel, I see your point about LLVM and C/C++ type agnostic. I think TBAA was invented to partially cover this gap and give optimization opportunities when LLVM types are not sufficient but C/C++ types have required information. What do you think about following example: struct S { int a[10]; int b; }; int foo(struct S *ps, int i) { ps->a[i] = 1; ps->b = 2; return

If I understand you correctly, conceptually you want two different objects to be returned for Foo.bl and Foo.al? Here is my take on this (take this with a grain of salt, Dan is the expert on this): http://llvm.org/docs/GetElementPtr.html#what-happens-if-an-array-index-is-out-of-bounds LLVM's semantic allows for arrays to be accessed out of bounds - this allows you to walk from the first

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

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

I found a something that I quite not understand when compiling a common piece of code using the -Os flags. I found it while testing my own backend but then I got deeper and found that at least the x86 is affected as well. This is the referred code: char pp[3]; char *scscx = pp; int tst( char i, char j, char k ) { scscx[0] = i; scscx[1] = j; scscx[2] = k; return 0; } The above gets

Hi all, I have a question regarding dynamic indexing into a vector with GEP. I see that in the ScalarReplAggregates pass in the LLVM 3.2 release the call SROA::isSafeGEP() will now allow alloca scalarization in the case where a GEP index into a vector isn’t a constant. My question is: what is the expected behavior when the index is out of bounds of the vector? Is it undefined? I have an

Hi, Does this kind of IR have "undefined behavior" under LLVM semantics or is it acceptable? (TLDR: a store of i64 at offset n, followed by a load of i32 at offset n+1.) define void @foo(i32* %A, i64 %n) { entry: %arrayidx = getelementptr inbounds i32, i32* %A, i64 %n %arrayidx_cast = bitcast i32* %arrayidx to i64* store i64 0, i64* %arrayidx_cast, align 4 %add1 = add i64 %n,

Hi, Is the -indvars pass functional? I've done some small test to check it, but this fails to canonicalize: > int *x; > int *y; > int i; > ... > for (i = 1; i < 100; i+=2) { > x[i] = y[i] + 3; > } The IR produced after -indvars: > br label %for.cond > > for.cond: ; preds = %for.inc, %entry > %indvars.iv =