similar to: Is it ok to allocate > half of address space?

Many thanks for the pointer! I missed that bug report since the title was about GVN. If there's interest in supporting this feature I can help since we've formalized most of BasicAA. I can easily verify if proposed changes are correct. (I'll release the code soon). Nuno Quoting Björn Pettersson A <bjorn.a.pettersson at ericsson.com>: > Hi Nuno. > I can't

>On 11/8/2017 9:24 AM, Nuno Lopes via llvm-dev wrote: >> Hi, >> >> I was looking into the semantics of GEP inbounds and some BasicAA rules >> and I'm wondering if it's valid in LLVM IR to allocate more than half of >> the address space with a global variable or an alloca. >> If that's a scenario want to consider, then we have problems :)

> On Dec 27, 2016, at 11:09 PM, liuyu11 at ict.ac.cn via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hello,everyone: > I want to known how to let clang compile my local array to local variables: > I have the code : > int main() > { > int a[3]={1,2,3}; > > int b=7; > int c=8; > int d=9; > int e=10; > int f=11; >

Hello,everyone: I want to known how to let clang compile my local array to local variables: I have the code : int main() { int a[3]={1,2,3}; int b=7; int c=8; int d=9; int e=10; int f=11; test(b,c,d,e,f,a); return 0; } I use clang command:clang --target=mipsel -emit-llvm -S a.c -o a.ll The a.ll is: @main.a = private unnamed_addr constant [3 x i32] [i32 1, i32 2, i32 3],

My understanding is that alias analysis returns results in the function scope, not in loop scope. Since both the phis access both global arrays, that should results in BasicAA conservatively returning MayAlias. I debugged this a little bit and narrowed it down to the section of the code in BasicAAResult::aliasPHI() which has this comment- // Analyse the PHIs' inputs under the assumption

Hi Hal, In that case what is the best way to query whether there is a loop carried dependence between B[j] and A[j] at i-loop level? We were operating under the assumption of 'conservatively correct' behavior of alias analysis in the function scope? Thanks, Pankaj From: Finkel, Hal J. <hfinkel at anl.gov> Sent: Tuesday, March 17, 2020 11:50 AM To: Hiroshi Yamauchi <yamauchi at

Hi all, I have this test case- #define N 1000 extern double Ag[N]; extern double Bg[N]; void consume(double *A, double *B); void swap_deps() { double *A = Ag; double *B = Bg; for (int i = 0; i < 97; ++i) { for (int j = 0; j < N; ++j) { B[j] = A[j] + 1; } double *tmp = A; A = B; B = tmp; } consume(A, B); } BasicAA is returning 'NoAlias' when

> On 07/14/2017 04:37 PM, Nuno Lopes wrote: >> Thank you all for your replies. >> So here seems to be an agreement that the documentation for PartialAlias >> is incorrect. >> >> Daniel: now you got me wondering about MustAlias. This is what the docs >> say: >> "The MustAlias response may only be returned if the two memory objects >> are

Hi, I have a doubt with GEP transformation in the instruction-combiner. Consider below test-case: struct ABC { int A; int B[100]; struct XYZ { int X; int Y[100]; } OBJ; }; void Setup(struct ABC *); int foo(int offset) { struct ABC *Ptr = malloc(sizeof(struct ABC)); Setup(Ptr); return Ptr->OBJ.X + Ptr->OBJ.Y[33]; } Generated IR for the test-case: define i32 @foo(i32

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

I changed the input C to using a 64 bit type for the loop index (this eliminates 'sext' instructions in the IR) Here the IR produced with clang -O0 define float @foo(i64 %start, i64 %end, float* %A) #0 { entry: %start.addr = alloca i64, align 8 %end.addr = alloca i64, align 8 %A.addr = alloca float*, align 8 %sum = alloca [4 x float], align 16 %i = alloca i64, align 8

On 7 November 2013 17:18, Frank Winter <fwinter at jlab.org> wrote: > LV: We don't allow storing to uniform addresses > This is triggering because it didn't recognize as a reduction variable during the canVectorizeInstrs() but did recognize that sum[q] is loop invariant in canVectorizeMemory(). I'm guessing the nested loop was unrolled because of the low trip-count, and

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() { >>>>

Thank you all for your replies. So here seems to be an agreement that the documentation for PartialAlias is incorrect. Daniel: now you got me wondering about MustAlias. This is what the docs say: "The MustAlias response may only be returned if the two memory objects are *guaranteed to always start at exactly the same location*" This statement is regardless of the access sizes. For

I am trying my luck on this global reduction kernel: float foo( int start , int end , float * A ) { float sum[4] = {0.,0.,0.,0.}; for (int i = start ; i < end ; ++i ) { for (int q = 0 ; q < 4 ; ++q ) sum[q] += A[i*4+q]; } return sum[0]+sum[1]+sum[2]+sum[3]; } LV: Checking a loop in "foo" LV: Found a loop: for.cond1 LV: Found an induction variable. LV: We

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

Hello all, I observed that BasicAA alias query returns PartialAlias between different fields of a structure. Following is the test program and -print–all-alias-modref-info output: --- ; test.ll target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-unknown-linux-gnu" %"type" = type { [10 x i32], i64 } define void

> On Thu, Aug 10, 2017 at 12:22 AM, Nema, Ashutosh via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> I’m not sure how transforming GEP offset to i8 type will help alias >> analysis & SROA for the mentioned test case. > > It should neither help nor hinder AA or SROA -- the two GEPs (the complex one and the simple one) are equivalent. > Since memory isn't

Hello All, I have met a case with restrict keyword and I have a question about it. Let's look at a simple example. char buf[4]; void test(char *restrict a, char *restrict b, int count) {   for (unsigned i = 0; i < count; i++) {     *a = *b;     a++;     b++;     buf[i] = i;   } } I think there are no aliasing among pointers such as 'a', 'b' and 'buf'

Hi, We've seen a similar case recently, where BasicAA returns PartialAlias for the access of two different fields of a structure. We noticed this since Lint complained about it when checking for aliasing beteen "noalias" attributed parameters: opt -S -lint ./alias.ll gave Unusual: noalias argument aliases another argument on the (silly) function: %rec7 = type { i16, i16, i16