similar to: [LLVMdev] @llvm.memset.* documentation

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

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]* @global_array_char, i32 0, i32 0), i8 %12, i32 %smax36, i32 1, i1 false)

I can't think of a better way to do this, so I think it's ok. I also submitted a complementary patch on llvm-commits clarifying volatile semantics. -Andy On Jan 28, 2013, at 8:54 AM, Arnaud A. de Grandmaison <arnaud.allarddegrandmaison at parrot.com> wrote: > Hi All, > > In the language reference manual, the access behavior of the memcpy, > memmove and memset

Dear llvm contributors, Could you please advise me where objects of MemoryLocation class are created for ‘llvm.memset.*‘ intrinsics? In the Bug 23077 (https://llvm.org/bugs/show_bug.cgi?id=23077) the AliasSetTracker constructs 128 alias sets for 0 pointer values, which contain only unknown instructions. In this case, all unknown instructions, which are added to new alias sets in the

> Please start a thread on llvmdev about this functionality, and outline what other intrinsics will have to change to add non-8-bit byte support. Well, memset is the only we have seen so far (our back-end is ~50% finished for an initial release). We have our own front-end as well (we are currently not using the clang front-end), and currently don't use many llvm intrinsics (only

Hi All, In the language reference manual, the access behavior of the memcpy, memmove and memset intrinsics is not well defined with respect to the volatile flag. The LRM even states that "it is unwise to depend on it". This forces optimization passes to be conservatively correct and prevent optimizations. A very simple example of this is : $ cat test.c #include <stdint.h>

IR: define i32 @calloc_strlen_write_between() { %call = tail call noalias i8* @calloc(i32 10, i32 1) store i8 97, i8* %call, align 1 %call1 = tail call i32 @strlen(i8* %call) ret i32 %call1 } static bool eliminateStrlen(CallInst *CI, BasicBlock::iterator &BBI, AliasAnalysis *AA, MemoryDependenceResults *MD, const DataLayout &DL, const TargetLibraryInfo *TLI,

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 Alexandre, Before the change you would have been expecting one of the following, correct? a) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8 addrspace(1)* [[APTR]], i64 2048, i32 0, i1 false) b) call void @llvm.memcpy.p3i8.p1i8.i64(i8 addrspace(3)* bitcast ([512 x float] addrspace(3)* [[SPM0]] to i8 addrspace(3)*), i8

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

Yeah, sorry for that. Better "It compiles ok (but maybe incorrect code)", not "It works" as I wrote. 2018-05-23 1:08 GMT+02:00 Friedman, Eli <efriedma at codeaurora.org>: > You might want to look more carefully at how you're constructing the > MemoryLocation. The first argument is a pointer, and the second argument > is the number of bytes pointed to by

On 12/17/2010 02:01 PM, Bruno Cardoso Lopes wrote: > Hi Richard, > >> You changes work for me also. I applied something similar to the Mips CG >> and they worked there also. Thanks again. > > I can't reproduce the same problem here for Mips using clang, could > you please attach the bitcode you used? > Thanks > Hi Bruno, This was the bitcode from a simple

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

You might want to look more carefully at how you're constructing the MemoryLocation.   The first argument is a pointer, and the second argument is the number of bytes pointed to by that pointer (or MemoryLocation::UnknownSize if the number of bytes accessed isn't known). More generally, copy-pasting code you don't understand isn't a good idea. -Eli On 5/22/2018 4:02 PM, Dávid

Good question. AFAIK, the IR-printer doesn’t understand the semantics of parameter attributes. In this case, it only knows that there is an attribute on the parameter that is integer valued (with value 1) and that has the name “align”, so it prints it out. If we don’t want it printing out ‘align 1’ then it’s up to us to not set the alignment parameter attribute to a value if that value would be 1.

Hi, I have, in postres, a piece of IR that, after inlining and constant propagation boils (when cooked on really high heat) down to (also attached for your convenience): source_filename = "pg" target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux-gnu" define void @evalexpr_0_0(i8* align 8 noalias, i32* align 8 noalias) {

Prompted by a SO post (http://stackoverflow.com/questions/9441882/compiler-instruction-reordering-optimizations-in-c-and-what-inhibits-them/9442363) I checked and found that LLVM yields the same (seemingly) suboptimal code as MSVC. Consider the following, simplified, C snippet: extern void bar(int*); void foo(int a) { int ar[100] = {a}; if (a) return; bar(ar); }

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