similar to: [LLVMdev] Call to non-constant memset() being generated where libc is not available

David Meyer wrote: > I am compiling something without standard libraries, including no libc. > > Somehow, this bitcode is being generated by plain array manipulation code: > > %12 = add i8 %11, -19 > %tmp35 = icmp sgt i32 %9, 1 > %smax36 = select i1 %tmp35, i32 %9, i32 1 > call void @llvm.memset.p0i8.i32(i8* getelementptr inbounds ([100 x > i8]*

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

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, are the llvm.memset.p0i8.i32 and llvm.memset.p0i8.i64 intrinsics meant to be used for 32-bit and 64-bit architectures, respectively depending on the module's target datalayout? Or can I use any of them? If yes, why are there two functions? Sorry, if it's obvious, but the documentation wasn't that clear. Thanks and ciao, Mario

On Jan 18, 2018, at 10:48 PM, Chris Lattner <clattner at nondot.org<mailto:clattner at nondot.org>> wrote: On Jan 18, 2018, at 7:45 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Hi all, This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in:

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

> On Jan 18, 2018, at 7:45 AM, Daniel Neilson via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > Hi all, > This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in: https://reviews.llvm.org/D41675 <https://reviews.llvm.org/D41675> ). The process that we’re going to use for landing this will take a few

We are seeing some behavior we don't understand. Some of our functions are not showing up in the Call Graph because their calls contain bitcasts. The Call Graph then considers them to be external nodes. The calls look as follows: %tmp35 = call i32 (...)* bitcast (i32 (i32, i8*, i32*)* @convert to i32 (...)*)( i32 %tmp33, i8* %tmp34, i8* %tmp30 ) ; <i32> [#uses=1] After looking

Good day all, I’ve spent a few days resurrecting the circa-2015 work on removing the explicit alignment argument (4th arg) from the @llvm.memcpy/memmove/memset intrinsics in favour of using the alignment attribute on the pointer args of calls to the intrinsic. This work was first proposed back in August 2015 by Lang Hames: http://lists.llvm.org/pipermail/llvm-dev/2015-August/089384.html (item

On Thu, Jun 27, 2019 at 4:58 PM Saleem Abdulrasool <compnerd at compnerd.org> wrote: > For what it is worth, I do believe that these files do really belong in > the libc project because they are so intricately tied to the implementation > of the language. I just think that the fact these files will be part of > the project is merely an implementation detail and should not even

Hello, What intrinsics "@llvm.lifetime.start/@llvm.lifetime.end" really do? As per my knowledge, they define the live ranges of variables. In the following code section, they seem redundant. However, when I remove them, the behavior of the code becomes non-deterministic. The live ranges of the variables defined by them are never used in the code. Thanks, --------------- %37 = bitcast

Hi all, A quick note just to let people know that as of this past Friday my go at this work has been fully landed. It ended up being a back-burner item, so it took longer than I would have liked to get completed. None the less, the changes made were: 1) The IRBuilders in LLVM, Clang, and Polly were all updated to create only the new form of the memory intrinsics. 2) All LLVM passes to understand

Hi all, This change has been reviewed, and appears to be ready to land (review available here if anyone still wants to chime in: https://reviews.llvm.org/D41675 ). The process that we’re going to use for landing this will take a few steps. To wit: Step 1) Remove align argument, and add align attribute to pointer args. Require that src & dest have the same alignment via verifier rule. Also

Hi Daniel, a quick question (and kind-of a follow-up to <https://lists.llvm.org/pipermail/llvm-dev/2017-July/115665.html>): Do the pointers have to be aligned even if the size is 0? It would be nice to have this stated explicitly in the LangRef. Kind regards, Ralf On 26.03.2018 22:43, Daniel Neilson via llvm-dev wrote: > Hi all, >  A quick note just to let people know that as of

Hi all, I observed the nature of the LLVM IR and because of the SSA form, it does not preserve function local variable names (like it preserves function argument names). Is there any way to track these local variables? Basically what I am doing is interpreting the IR against an abstract machien where I need to store the value of each program variable at any instance. Here I would get values for

Hi All, I have a question on ConstantExpressions and llvm intrinsic memcpy/memset/memmove. I am using llvm-2.8 release. In one of the C programs that I am compiling using clang frontend, the call to memcpy instrinsic looks like the following call void @llvm.memcpy.p0i8.p0i8.i64(i8* %tmp2, i8* bitcast (%struct.ta* @tret to i8*), i64 4, i32 4, i1 false), !dbg !19 The second argument to memcpy is

Hello everybody, I have stumbled upon a test case (the attached module is a slightly reduced version) that shows extremely reduced performance on linux compared to windows when executed using LLVM's JIT. We narrowed the problem down to the actual code being generated, the source IR on both systems is the same. Try compiling the attached module: llc -O3 -filetype=asm -o BAD.s BAD.ll Under

On Sep 29, 2010, at 8:35 AMPDT, Ralf Karrenberg wrote: > Hello everybody, > > I have stumbled upon a test case (the attached module is a slightly > reduced version) that shows extremely reduced performance on linux > compared to windows when executed using LLVM's JIT. > > We narrowed the problem down to the actual code being generated, the > source IR on both systems

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

On 11/11/2015 8:53 AM, Hal Finkel wrote: > > SROA seems to be doing a number of things here. What about if we prevented SROA from generating multiple slices splitting volatile accesses? There might be a significant difference between that and something like this test (test/Transforms/SROA/basictest.ll): > > define i32 @test6() { > ; CHECK-LABEL: @test6( > ; CHECK: alloca i32 >

Hi all, LLVM is smart that it can synthesize llvm.memset, llvm.memcpy etc. from loops, which can be lowered into calls to memset, memcpy and so on. Is there an option that can disable this optimization? For some cases, I do not want the code to depend on libc. Thanks in advance! Bin -------------- next part -------------- An HTML attachment was scrubbed... URL: