search for: memmov

Displaying 20 results from an estimated 584 matches for "memmov".

Did you mean: memmove
2000 Jan 19
1
Potentially serious (but rare) issue with buffer.c and cipher.c
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...
2020 Sep 18
3
GC-parseable element atomic memcpy/memmove
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...
2018 Jan 18
0
Change memcpy/memmove/memset to have dest and source alignment attributes
...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...
2018 Jan 02
5
Change memcpy/memmove/memset to have dest and source alignment attributes
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...
2013 Jan 31
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
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...
2013 Feb 03
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
...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...
2018 Mar 26
1
Change memcpy/memmove/memset to have dest and source alignment attributes
...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...
2013 Jan 28
4
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
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...
2018 Apr 02
0
Change memcpy/memmove/memset to have dest and source alignment attributes
...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 —...
2013 Oct 12
1
[PATCH] btrfs: Fix improper memmove usage in do_btrfs_subvolume_list
...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
2020 Sep 30
2
GC-parseable element atomic memcpy/memmove
...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...
2007 Oct 06
1
[LLVMdev] memcpy(), memmove(), and memset() with zero length
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
2006 Mar 03
0
[LLVMdev] Re: Re: New GCC4-based C/C++/ObjC front-end for LLVM
...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, -...
2013 Jan 29
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
...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 : >...
2004 Aug 02
4
reducing memmoves
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...
2015 Jan 09
3
[LLVMdev] Can we assume const parameter and to-be-modified parameter do not alias?
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
2018 Jan 19
2
Change memcpy/memmove/memset to have dest and source alignment attributes
...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...
2015 Aug 19
3
[RFC] Generalize llvm.memcpy / llvm.memmove intrinsics.
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...
2015 Aug 18
2
Aggregate load/stores
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...
2017 Jul 20
2
Which assumptions do llvm.memcpy/memmove/memset.* make when the count is 0?
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...