similar to: Field sensitive alias analysis?

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

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

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

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 , 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

Hello All, I have a question about a May-alias case. Let's look at one simple C example. char *buf[4]; char c; void test(int idx) {   char *a = buf[3 - idx];   char *b = buf[idx];   *a = *b;   c++;   *a = *b; } We can imagine the second "*a = *b" could be removed. Let's look at the IR snippet with -O3 for above example.   1 define void @test(i32 %idx) {   2 entry:  

Hi, I am new to MemorySSA and wanted to understand its capabilities. Hence I wrote the following program (test.c): int N; void test(int *restrict a, int *restrict b, int *restrict c, int *restrict d, int *restrict e) { int i; for (i = 0; i < N; i = i + 5) { a[i] = b[i] + c[i]; } for (i = 0; i < N - 5; i = i + 5) { e[i] = a[i] * d[i]; } } I compiled this program using

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 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 Nadav, Thanks for the quick reply !! Ok, so as of now we are lacking capability to handle flat large reductions. I did go through function vectorizeChainsInBlock() (line number 2862). In this function, we try to vectorize if we have phi nodes in the IR (several if's check for phi nodes) i.e we try to construct tree that starts at chains. Any pointers on how to join multiple trees? I

Hi, I am trying to understand LLVM vectorization implementation and was looking into both loop and SLP vectorization. test case 1: *int foo(int *a) {int sum = 0,i;for(i=0; i<16; i++) sum += a[i];return sum;}* This code is vectorized by loop vectorizer where we calculate scalar loop cost as 4 and vector loop cost as 2. Since vector loop cost is less and above reduction is legal to

Hi, It was a while now since I first asked about TBAA, and I am now getting back to this, trying to understand TBAA as it seems that the issue I described earlier originally in this thread is still one of many "TODO"s in CGExpr.cpp (http://lists.llvm.org/pipermail/llvm-dev/2018-September/126290.html). I would like to help on this to the best of my abilities, but I'm not quite

Daniel, Indulge me one more mail and I will go away … (or I'll try to :) On Feb 15, 2013, at 6:38 PM, Daniel Berlin <dberlin at dberlin.org> wrote: > yes, it does, but this is somewhat irrelevant to C. > > The pointers will not be of type struct.a[x] *, they will be of type > int (*[100])) or int * or whatever But using the type system, aliasing, and language rules you

The IR after LSR is: *** IR Dump After Loop Strength Reduction *** ; Preheader: entry: tail call void @fill_array(i32* getelementptr inbounds ([10 x i32], [10 x i32]* @buffer, i32 0, i32 0)) #2 br label %while.body ; Loop: while.body: ; preds = %while.body, %entry %lsr.iv = phi i32 [ %lsr.iv.next, %while.body ], [ 0, %entry ] %uglygep = getelementptr

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, 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. In my backend I get false code after using StrengthLoopReduction. In the generated code the loop index variable is multiplied by 8 (correct, everything is 64 bit aligned) to get an address offset, and the index variable is incremented by 1*8, which is not correct. It should be incremented by 1 only. The factor 8 appears again. I compared the debug output

But even for a very simple loop: int test1 (int *x, int *y, int *z, int k) { int sum = 0; for (int i = 10; i < k; i++) { z[i] = x[i] / y[i]; } return sum; } The initial value of induction variable is not zero after compiling with -O3 -mcpu=power8 x.cpp -S -c -emit-llvm -fno-unroll-loops (see bottom of the email for IR) Also I can write somewhat more complicated loop where step

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

Hm, no. I expect byte addresses - everywhere. The compiler should not know that the arch needs word addresses. During lowering LOAD and STORE get explicit conversion operations for the memory address. Even if my arch was byte addressed the code would be false/illegal. Boris > Am 09.06.2020 um 19:36 schrieb Eli Friedman <efriedma at quicinc.com>: > > Blindly guessing here,