search for: memmoved

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

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
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 effect on GC latencies
2018 Jan 18
0
Change memcpy/memmove/memset to have dest and source alignment attributes
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
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
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.
2013 Feb 03
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
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
2018 Mar 26
1
Change memcpy/memmove/memset to have dest and source alignment attributes
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
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 <stdint.h>
2018 Apr 02
0
Change memcpy/memmove/memset to have dest and source alignment attributes
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
2013 Oct 12
1
[PATCH] btrfs: Fix improper memmove usage in do_btrfs_subvolume_list
The third parameter (number of bytes to copy) was given as an offset relative to dest, when it should be relative to src. This fixes some valgrind warnings I happened 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 @@
2020 Sep 30
2
GC-parseable element atomic memcpy/memmove
Thanks for the feedback. I think both of the suggestions are very reasonable. I’ll incorporate them. Given there were no objections for two weeks, I’m going to go ahead with posting individual patches for review. One small question inline: On Sep 28, 2020, at 10:56 AM, Philip Reames <listmail at philipreames.com<mailto:listmail at philipreames.com>> wrote: In general, I am
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
On Thu, 2 Mar 2006, Chris Lattner wrote: >> Any ideas what could be wrong? > > Sorry for the delay, please try this tarball: > http://nondot.org/sabre/2006-03-02-llvm-gcc-4.tar.gz Actually, do to a recent change in CVS, this tarball will probably not work anymore. Please apply the attached (small) patch on top of it in the gcc directory. Worth noting, this front-end only works
2013 Jan 29
0
[LLVMdev] Specify the volatile access behaviour of the memcpy, memmove and memset intrinsics
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
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 seeing. Also, the memmove cost if obviously neglegible compared to real dis...
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
> 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
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 partial overlap). While the C
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
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 count is 0? On a pointer of less than the given