similar to: [LLVMdev] malloc / free & memcpy optimisations.

> could you allocate the memory on the stack instead (alloca instruction)? This is mainly for string or binary blob handling, using the stack isn't a great idea for size reasons. While I'm experimenting with simple code examples now, and I picked a simple one for this email. I'm certain things will get much more complicated once I implement more features of the language. On Tue,

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

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

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

Hi All, I have a program that uses C++ STL a lot. To have the source code for STL functions, I undefined "_GLIBCXX_EXTERN_TEMPLATE" in c++config.h. In spite of this, after compilation (via clang) and linking (via llvm-ld), the resulting bitcode contains a few declared functions (with no definitions). My question is: In the scenario where some function definitions are missing in a llvm

Guess I have found some clues. Some necessary libraries have to be loaded while trying to generate native code or do interpretation. Then another question emerges: Is there a way to determine the necessary libraries in need? And where to locate these necessary libraries? Xiaolong > Hi All, > > I have a program that uses C++ STL a lot. To have the source code for > STL functions, I

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

Thanks Duncan and Ashok, As Duncan described, "lli -load=libstdc++.dylib ..." works. I, however, encounted an "Illegal instruction" message, while I was trying to interpret a large program. So, does lli have a debug switch for dumping out the details for errors? Using llc is not that simple, and I have not gotten through the compilation process. For instance, "llc -o

Hi Xialong, > I have a program that uses C++ STL a lot. To have the source code for > STL functions, I undefined "_GLIBCXX_EXTERN_TEMPLATE" in > c++config.h. In spite of this, after compilation (via clang) and > linking (via llvm-ld), the resulting bitcode contains a few declared > functions (with no definitions). > > My question is: In the scenario where some

Hi Duncan, >> #include<stdio.h> >> #include<string.h> >> >> int main(int argc, char** argv){ >> >> char a[8] = "aaaaaaa"; >> char b[8] = "bbbbbbb"; >> >> char *c = (char*) malloc(sizeof(char)*(strlen(a)+strlen(b)+1)); >> memcpy(c, a, strlen(a)); >> memcpy(c + strlen(a), b, strlen(b) + 1); >>

Hi Xiaolong, > As Duncan described, "lli -load=libstdc++.dylib ..." works. I, > however, encounted an "Illegal instruction" message, while I was > trying to interpret a large program. are you using the interpreter or the JIT? So, does lli have a debug switch > for dumping out the details for errors? > > Using llc is not that simple, and I have not gotten

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

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 =

Hi Pablo, I can reproduce this with the supplied IR. It is related to the use of __memcpy_chk. As far as I can see it is a bug in lli or the LLVM code generators. Can you please open a bugreport, attaching the LLVM IR. Ciao, Duncan. On 23/01/12 17:00, Pablo Barrio wrote: > Hi Duncan, >>> #include<stdio.h> >>> #include<string.h> >>> >>> int

Hi I am upgrading my clang fork from 5.0 to 6.0 and I am hit by this error: Access type node must be a valid scalar type %4 = load %"struct.Foo::p.test1::"*, %"struct.Foo::p.test1::"** %_param.addr, align 8, !tbaa !16 !16 = !{!15, !15, i64 0} !15 = !{!"p.test1::", !13, i64 0, !13, i64 8} It looks like !16 is referencing !15, which is a struct. !13 is !13 =

Hi Duncan, On 11/10/12 15:47, Duncan Sands wrote: > Hi Roel, > >> When going through the internals of the old C back-end, I see that the CBE >> encapsulates arrays into a struct. The source code has the following comment to >> explain this behaviour. >> >> // Arrays are wrapped in structs to allow them to have normal >> // value semantics

Hi, I have an ir at the end of this email. Run it with: llc -mcpu=i386 -march=x86-64 -mattr=-sse2 and get assertion below. Changing cpu does not help. I am using llc from the latest svn repository. Any suggestions to work around this? I need to disable sse2 instructions for x86-64. Thanks, -Peng -----error message------ llc: X86FloatingPoint.cpp:332: unsigned int getFPReg(const

Hi, I've been stuck with this problem for a while now, and my supervisor's starting to think it's a bug in lli, but I thought I'd ask here before going down that route. I have this code, which stores an array in my 'MainClass', and prints out an element of it. Note that the print statement is irrelevant here, it segfaults regardless, and this code has been run with -O2

Hi all, Consider the following example: define void @fn(i8* %buf) #0 { entry: %arrayidx = getelementptr i8* %buf, i64 18 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %arrayidx, i8* %buf, i64 18, i32 1, i1 false) %arrayidx1 = getelementptr i8* %buf, i64 18 store i8 1, i8* %arrayidx1, align 1 tail call void @llvm.memcpy.p0i8.p0i8.i64(i8* %buf, i8* %arrayidx, i64 18, i32 1, i1 false)

> We at Azul have been using invariant.start for marking objects as immutable after a certain point. > Also, upstream changes to teach relevant optimizations about invariant.start and end were added > last year. > > With respect to store to load forwarding, this is handled in GVN. I think the test cases in test/Transforms/GVN/invariant.start.ll > handle what you’re looking for.