search for: memmov

While rototilling packet.c, I did some looking at cipher_encrypt in cipher.c. It ends up that for SSH_CIPHER_NONE in cipher_encrypt, it uses memcpy. However, it also appears that dest and src can be equal in cipher_encrypt. On most sane libc implementations, memcpy == memmove. However, ANSI C makes no such guarantee, and some implementations out there are bound to try to optimize memcpy eventually. Therefore, I've hacked out the following patch to change what may be "dangerous" memcpy's to memmove. Take a look and see what you think. Thanks, David...

TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative eff...

...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 update Clang & Polly tests to pattern-match the new form. Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. Step 3) Update Clang to use the new IRBuilder API. Step 4) Update Polly to use the new IRBuilder API. Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|set]Alignment() t...

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 2) and an attempt at landing the work was made by Pe...

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. 0002-memcpy-memmove-set-volatile-on-the-source-or-destina.patch impleme...

...patches, but could not for the actual ones as they touch llvm and clang. Cheers, -- Arnaud A. de Grandmaison On 01/31/2013 06:13 PM, Arnaud A. de Grandmaison wrote: > 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. > > 0002-memcpy-memmove-set-volatile-on-th...

...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 the new forms of the intrinsics; modulo the notes below. 3) The IRBuilder APIs for creating the old-style memcpy/memmove/memset forms and the MemIntrinsicInst API for getting/setting the old generic/conservative alignment have all been eliminated. There are a few places where the LLVM pass updates were conservative, and could potentially be made more aggressive by a motivated individual — list below. All that re...

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

...de > 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 the new forms of the intrinsics; modulo the > notes below. > 3) The IRBuilder APIs for creating the old-style memcpy/memmove/memset forms and > the MemIntrinsicInst API for getting/setting the old generic/conservative > alignment have all been eliminated. > >  There are a few places where the LLVM pass updates were conservative, and could > potentially be made more aggressive by a motivated individual —...

...across. --- daemon/btrfs.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/daemon/btrfs.c b/daemon/btrfs.c index c3247ac..765dec6 100644 --- a/daemon/btrfs.c +++ b/daemon/btrfs.c @@ -473,7 +473,7 @@ do_btrfs_subvolume_list (const mountable_t *fs) #undef XSTRTOU64 - memmove (line, line + ovector[6], ovector[7] + 1); + memmove (line, line + ovector[6], ovector[7] - ovector[6] + 1); this->btrfssubvolume_path = line; } -- 1.8.3.1

...39;t want to rely on it. Do you think it makes sense to control this aspect of lowering (derived pointers vs base+offset in memcpy args) using GCStrategy? Artur Philip On 9/18/20 4:51 PM, Artur Pilipenko via llvm-dev wrote: TLDR: a proposal to add GC-parseable lowering to element atomic memcpy/memmove instrinsics controlled by a new "requires-statepoint” call attribute. Currently llvm.{memcpy|memmove}.element.unordered.atomic calls are considered as GC leaf functions (like most other intrinsics). As a result GC cannot occur while copy operation is in progress. This might have negative eff...

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

...SBP)); Ops.push_back(CastToType(SrcPtr, SBP)); - Ops.push_back(CastToType(Size, Type::UIntTy)); + Ops.push_back(CastToType(Size, IntPtr)); Ops.push_back(ConstantUInt::get(Type::UIntTy, Align)); new CallInst(MemCpy, Ops, "", CurBB); } @@ -811,14 +815,17 @@ void TreeToLLVM::EmitMemMove(Value *Dest unsigned Align) { const Type *SBP = PointerType::get(Type::SByteTy); static Function *MemMove = 0; - if (!MemMove) - MemMove = TheModule->getOrInsertFunction("llvm.memmove", Type::VoidTy, SBP, -...

...so 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 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 : >...

Attached is a patch that makes window strides constant when files are walked with a constant block size. In these cases, it completely avoids all memmoves. In my simple local test of rsyncing 57MB of 10 local files, memmoved bytes went from 18MB to zero. I haven't tested this for a big variety of file cases. I think that this will always reduce the memmoves involved with walking a large file, but perhaps there's some case I'm not see...

Hi, This question is raised from the following example: int foo (const int a[], int b[]) { ... b[i] = … … } Basically a[] is defined as read-only while b[] will be explicitly modified in the function. At the first glance, they can not be alias but it seems that we can not figure out the alias info between them now which prevent us from doing some optimizations. Here is the

...aligned pointers would require casts, which then interfere with optimizations. -Chris > Require that src & dest have the same alignment via verifier rule. Also update Clang & Polly tests to pattern-match the new form. > Step 2) Expand the IRBuilder API to allow creation of memcpy/memmove with differing source and dest alignments. > Step 3) Update Clang to use the new IRBuilder API. > Step 4) Update Polly to use the new IRBuilder API. > Step 5) Update LLVM passes that create memcpy/memmove calls to use the new IRBuilder API, and those that use use MemIntrinsicInst::[get|se...

Hi All, I'd like to float two changes to the llvm.memcpy / llvm.memmove intrinsics. (1) Add an i1 <mayPerfectlyAlias> argument to the llvm.memcpy intrinsic. When set to '1' (the auto-upgrade default), this argument would indicate that the source and destination arguments may perfectly alias (otherwise they must not alias at all - memcpy prohibits part...

deadal nix via llvm-dev wrote on Mon, 17 Aug 2015: > OK, what about that plan : > > Slice the aggregate into a serie of valid loads/stores for non atomic ones. > Use big scalar for atomic/volatile ones. > Try to generate memcpy or memmove when possible ? Are memcpy/memmove guaranteed to be handled inline, i.e., without a call to libc? Or are there plans to do this in the context of the (afaik) long term goal of enabling llvm to (optionally) generate freestanding code? If not, generating memcpy/memmove seems like a bad idea...

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