Displaying 4 results from an estimated 4 matches for "movnti".
Did you mean:
movnt
2008 Nov 20
10
issues with movnti emulation
We''ve got reports of that change causing HVM data corruption issues. While
I can''t see what''s wrong with the patch, I''d suggest at least reverting it from
the 3.3 tree (which is what our code is based upon) for the time being.
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
2010 Jan 05
1
[LLVMdev] Non-temporal moves in memset [Was: ASM output with JIT / codegen barriers]
...emporal
>>>>> store to memory. This exempts it from all ordering considerations
Hm...off topic from my original email since I think this is only
relevant for multithreaded code...
But from what I can tell, an implementation of memset that does not
contain an sfence after using movnti is considered broken. Callers of
memset would not (and should not need to) know that they must use an
actual memory barrier (sfence) after the memset call to get the usual
x86 store-store guarantee.
Thread describing that bug in glibc memset implementation:
http://sourceware.org/ml/libc-alph...
2010 Jan 05
0
[LLVMdev] ASM output with JIT / codegen barriers
On Mon, Jan 4, 2010 at 8:51 PM, Jeffrey Yasskin <jyasskin at google.com> wrote:
> On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote:
>> On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote:
>>> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that
>>> I *only* care about
2010 Jan 05
3
[LLVMdev] ASM output with JIT / codegen barriers
On Mon, Jan 4, 2010 at 8:43 PM, Chandler Carruth <chandlerc at google.com> wrote:
> On Mon, Jan 4, 2010 at 1:13 PM, James Y Knight <foom at fuhm.net> wrote:
>> Hi, thanks everyone for all the comments. I think maybe I wasn't clear that
>> I *only* care about atomicity w.r.t. a signal handler interruption in the
>> same thread, *not* across threads. Therefore,