similar to: Bug in pass 'ipsccp' on function attribute 'argmemonly'?

Thank you Hal and Stefan! Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 And Stefan, I think 'attributor' is a really nice pass, and can infer more precise and useful attributes, which may give more opportunities for optimization. But we shouldn't depend on 'attributor' to correct wrong function attributes, because we cannot run 'attributor' after

On 7/14/20 4:34 PM, Hal Finkel via llvm-dev wrote: > > On 7/14/20 11:28 AM, Fangqing Du wrote: >> Thank you Hal and Stefan! >> >> Bug report is filed: https://bugs.llvm.org/show_bug.cgi?id=46717 >> <https://bugs.llvm.org/show_bug.cgi?id=46717> >> >> And Stefan, >> I think 'attributor' is a really nice pass, and can infer more >>

On 4/29/20 4:12 PM, Reid Kleckner via llvm-dev wrote: > On Tue, Apr 28, 2020 at 12:58 PM Ejjeh, Adel via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> Specifically, I want to be able to know when a called function does not >> have any side effects (e.g. math library functions like sqrt) >> > > Apologies for the pedantry, but I believe sqrt may

Hi, I’ve come back and updated my llvm toolset with modern code (my branch was about 1-2 years old) and now the llvm IR files produced by my front end no longer compile with llc. Here is a sample of llvm ir produced by my front end (it’s a standard version 3.1 build of swift from the swift.org open source website). ; ModuleID = 'main.ll' source_filename = "main.ll" target

[AMD Official Use Only - Internal Distribution Only] Hi, Following issue is observed with Type Based Alias Analysis(TBAA). ####################################################### 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, &(p.f2)); }

Here is original C code: void topup(int a[], unsigned long i) { for (; i < 16; i++) { a[i] = 1; } } Here is the IR before the pass where I expect SCEV to return trip-count value ; Function Attrs: nofree norecurse nounwind uwtable writeonly define dso_local void @topup(i32* nocapture %a, i64 %i) local_unnamed_addr #0 { entry: %cmp3 = icmp ult i64 %i, 16 br i1

That’s useful info, thanks. I think it will be useful for me to understand the connection, why this type of pointer is being emitted now. Do you have any suggestions where i can look to find the platform specific code that is making function pointers go into addrspace? Carl p.s. I am also working on passing the avr target flag to swift, but swift itself had (has?) limitations that make it

On 03/21/2016 08:54 AM, Nicolai Hähnle wrote: > On 19.03.2016 14:47, Philip Reames wrote: >> I'm generally in support of this change. I haven't looked at the patch >> yet, but the direction seems worthwhile. >> >> Note that we already have a writeonly predicate in a few places in the >> code (BasicAA being one). If we do introduce the new intrinsic

The frontend code is a pretty simple for loop, that counts from i = 0; i != 10; i += 1 It gets optimized into and endless loop. export fn entry() void { var array: [10]Bar = undefined; var x = for (array) |elem, i| { if (i == 1) break elem; } else bar2(); } Here's the generated IR: ; ModuleID = 'test' source_filename = "test" target datalayout =

The new @llvm.memcpy API does not have an alignment parameter. Instead the docs say to use the align <n> attribute. How is this supposed to work with different alignments? For example, I have one memcpy with align 4, align 4, and another with align 1, align 1. ; Function Attrs: argmemonly nounwind declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture writeonly align 4, i8* nocapture

Hi, I am observing a strange behaviour in which Clang ignores __restirct when I include some standard headers. For example, this code: void vec_add(int* __restrict a, int* __restrict b, int n) { #pragma unroll 4 for(int i=0; i<n; ++i) { a[i] += b[i]; } } results in: ; Function Attrs: nofree norecurse nounwind define dso_local void @_Z7vec_addPiS_i(i32*

On 19.03.2016 14:47, Philip Reames wrote: > I'm generally in support of this change. I haven't looked at the patch > yet, but the direction seems worthwhile. > > Note that we already have a writeonly predicate in a few places in the > code (BasicAA being one). If we do introduce the new intrinsic > property, we should refactor all of these places to use the new >

Cool. That explains a lot! Sorry if this is a total n00b question, but… how does the datalayout string get overridden? in llvm/lib/Target/AVR/AVRTargetMachine.cpp I can see the code that determines the default datalayout for AVR… static const char *AVRDataLayout = "e-P1-p:16:8-i8:8-i16:8-i32:8-i64:8-f32:8-f64:8-n8-a:8”; However in the LLVM iR below, the target datalayout was present and

Hello all, I have a custom allocator, and would like to teach LLVM about its semantics. In particular, I would like LLVM to kill allocations that are "dead", similar to dead new in C++. Consider this example: ; ModuleID = '<stdin>' source_filename = "Module" ; Function Attrs: inaccessiblememonly noinline norecurse nounwind declare i8* @alloc(i64)

On 3/22/2018 3:15 PM, Andrew Kelley via llvm-dev wrote: > The new @llvm.memcpy API does not have an alignment parameter. Instead > the docs say to use the align <n> attribute. How is this supposed to > work with different alignments? > > For example, I have one memcpy with align 4, align 4, and another with > align 1, align 1. > > ; Function Attrs: argmemonly

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

Hey list, I've recently done the first test run of bumping our Burst compiler from LLVM 10 -> 11 now that the branch has been cut, and have noticed an apparent loop vectorization codegen regression for X86 with AVX or AVX2 enabled. The following IR example is vectorized to 4 wide with LLVM 11 and trunk whereas in LLVM 10 it (correctly as per what we want) vectorized it 8 wide matching the

Hi All I am writing a pass which requires checking dependences, and am having trouble dealing with function calls. Specifically, I want to be able to know when a called function does not have any side effects (e.g. math library functions like sqrt), and was wondering if there are attributes that specify this behavior (I know there is the ‘noread’ attribute but wasn’t sure if there’s something

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

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