similar to: [LLVMdev] llvm instrinsic (memcpy/memset/memmov)and ConstantExpression with cast

On 4/14/11 6:34 PM, Kodakara, Sreekumar V wrote: > > 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

On Jul 22, 2009, at 1:37 PM, Jakub Staszak wrote: > Hello, > > This patch fixes PR2218. Very nice. Are you sure this fixes PR2218? The example there doesn't have any loads in it. > However, I'm not pretty sure that this optimization should be in > MemCpyOpt. I think that GVN is good place as well. Yes, you're right. My long term goal is to merge the relevant

Hello, Sorry for my stupid mistakes. I hope that everything is fine now. This patch fixes PR2218. There are no loads in example, however "instcombine" changes memcpy() into store/load. Regards, Jakub Staszak -------------- next part -------------- A non-text attachment was scrubbed... Name: pr2218-2.patch Type: application/octet-stream Size: 6525 bytes Desc: not available URL:

Dear all, I'm trying to locate all instances of a specific function call, identify one of it arguments and find where it was declared and defined. i can visit every instruction in each function, identify the appropriate CallInst, get the CallSite of the instruction and extract the appropriate (Value) argument with getArgument(X). Unfortunately I can't figure out how to get from the Value

> I don't think that was the conclusion of the discussion? I mean the > result was that a NULL pointer should be explicitly valid if the length > argument is zero. That's a bit more restrictive. Yeah there's a design space here. I don't care about the result but am volunteering to document whatever people want. John

If I copy or set zero bytes with memcpy(), memmove(), or memset(), can the <dest> and <src> arguments be null? Can they be invalid pointers? Regards, Jon

On Fri, Jul 21, 2017 at 09:31:41AM -0600, John Regehr via llvm-dev wrote: > I propose documenting in the LangRef that memcpy and related intrinsics are > defined even when src and dst don't refer to valid storage as long as the > length argument is zero. Then we commit to implementing that behavior. Is > that OK with everyone? If so I can update the doc. I don't think that was

Hi All, I am using llvm-3.0 release version for compiling some files. I have a cpp file on which I did a few custom passes. After that I used llc to convert the *.bc file to *.s file at -O1 optimization level. llc took ~2630 seconds to perform this conversion. I timed llc and these are the top three passes that is taking most of the time. ---User Time--- --System Time-- --User+System--

Hi All, I would like to know if there is an API/method that I can use to get the name of the file being processed in a dynamically loaded function pass. In other words, if I invoke a pass as follows opt -load pass.so -hello src.bc -o src.hello.bc where pass.so is a functionpass, I would like to get the filename "src.bc", in the doInitialization/doFinalization method. My intent is to

Hi, LLVM's memory intrinsics are quite useful for performing various optimizations with frequently used memory operations. Unfortunately this intrinsics are not applicable for languages with guaranteed atomicity for their memory accesses (like Java for example). In order to overcome this limitation I'm thinking about adding set of intrinsics which will execute as a series of unordered

> So, the pointer arguments of memcpy *shall* (a violation of a shall > clause is UB, per §4/2) have valid values, even though the function will > copy zero characters. This is true in C but the question was about LLVM intrinsics. Since the LangRef does not mention any such restriction, I would assume that memcpy(0,0,0) is not UB in LLVM. If it is UB then we must update the LangRef

Hi all, when I call the llvm.memcpy/memmove/memset.* intrinsics, typically I have to pass in valid (non-dangling, non-NULL pointers) of the given alignment. However, to what extent to these rules apply when the count is 0? Concretely (for any variant of the three aforementioned intrinsics): Is it UB to call them on a dangling pointer when count is 0? On a pointer of less than the given

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:

I have developed a pass to instrument LLVM bit code files with calls to a custom instrumentation library. For one of the instrumentation calls, I need to pass the name of the temporary variable used in LLVM bit code. For example, if I see LLVM assembly code as shown below, %13 = icmp eq i64 %11, 0, !dbg !14 After the instrumentation pass, it needs to look like the following %13 = icmp eq i64

As of earlier this year, we now explicitly ignore the nonnull attributes that glibc puts on memcpy (and other stdlib functions). I don't know how LLVM feels about dangling or underaligned pointers in particular, but AFAICT, we do try hard to make sure that memcpy(NULL, _, 0) works as the user probably intends. Here's the thread I read about it:

Thanks Andy and Chandler, After specifying the volatile access behaviour, the second step was to autoupgrade the memmove/memcpy intrinsics, and implement (is|set)Volatile in terms of (is|set)(Src|Dest)Volatile, with no functional change. 0001-Specify-the-access-behaviour-of-the-memcpy-memmove-a.patch is the one you already reviewed, unaltered.

On 7 July 2011 02:27, Kodakara, Sreekumar V <sreekumar.v.kodakara at intel.com> wrote: > I would like to know if there is an API/method that I can use to get the > name of the file being processed in a dynamically loaded function pass. In > other words, if I invoke a pass as follows > > opt  -load pass.so -hello  src.bc –o src.hello.bc > > where pass.so is a

Same patches as before, but 0002-memcpy has been updated to put the (is|set)SrcVolatile methods to where they logically belong : MemTransferInst. This makes (is|set)Volatile methods look a bit ugly to keep compatibility with existing behaviour, but they will hopefully disappear when all users have moved to the new interface --- in the next series of patches. I plan to give a try to phabricator

Hi R-helpers, I need to read some file with different lines (I don't know the number of lines to skip) and I would like to find a way to start reading the data.frame from the word "source". ex: djhsafk asdfhkjash shdfjkash asfhjkash #those lines contain numbers and words, I want to skip then but they have different sizes asdfhjkash asdfhjksa source tret 2 res 3 Can

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