search for: movnt

This thread from last year has some additional detail regarding the hazards of aggressive MOVNT generation if you’re interested: http://lists.llvm.org/pipermail/llvm-dev/2016-May/098980.html <http://lists.llvm.org/pipermail/llvm-dev/2016-May/098980.html> – Steve > On Sep 28, 2017, at 9:31 AM, Stephen Canon via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > What code...

What code did you write where you expected VMOVNTDQ to be generated? The x86 MOVNT instructions are something of an attractive nuisance. There are cases where they are beneficial, but those cases are much less common and harder to characterize than you might expect. LLVM is deliberately conservative about using MOVNT (IIRC it’s currently only gen...

Hello, i am using llvm 4.0 i am generating intel avx code. But in code i dont find VMOVNTDQ instruction. Why is that so? When does this instruction generated? Please clarify. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170928/9e34fd82/attachment-0001.html>

Right now the MemSDNode keeps a volatile bit in the SubclassData to mark volatile memory operations. We have some changes we'd like to push back that adds a NonTemporal flag to MemSDNode to mark instructions where movnt (on x86) and other goodness can happen (we'll also add the TableGen patterns to properly select movnt). In our tree we simply added another flag to the MemSDNode constructor and embedded it in SubclassData: MemSDNode(unsigned Opc, DebugLoc dl, SDVTList VTs, MVT MemoryVT, const Va...

...ontemporal attribute in LLVM, and the __builtin_nontemporal_* functions in Clang, is rather spartan and underspecified. In effect, it says the following things: * Atomic !nontemporal has no defined semantics * !nontemporal may use special instructions to save cache bandwidth, such as "MOVNT" on x86. What is crucially lacking from this specification is its effects in relation to other memory ordering constructs, namely fences. In lieu of text to the contrary, one could reasonably come to the conclusion that this code should be sufficient to generate correctly working code: store...

...an represent alignments up to 2^1024, which seems like a bit much. :) What do you think about carving four more bits out of the alignment field so we have five flag/semantic bits and can represent alignments up to 2^64? That seems like plenty of alignment headroom. > How are you representing movnt in LLVM IR, with an intrinsic? Yes, it's an intrinsic inserted just before the load or store of interest. I'm not particularly happy with this solution because I'm not sure all transformation passes will preserve the ordering of intrinsic-followed-by-operation. Is there a better w...

...1, 2009, at 11:26 AM, David Greene wrote: > Right now the MemSDNode keeps a volatile bit in the SubclassData to > mark > volatile memory operations. > > We have some changes we'd like to push back that adds a NonTemporal > flag > to MemSDNode to mark instructions where movnt (on x86) and other > goodness > can happen (we'll also add the TableGen patterns to properly select > movnt). > > In our tree we simply added another flag to the MemSDNode constructor > and embedded it in SubclassData: > > MemSDNode(unsigned Opc, DebugLoc dl, SDVTLis...

...its and can represent alignments up > to 2^64? > That seems like plenty of alignment headroom. Yes, that's fine too. If someone really wanted an alignment greater than 1<<64, they would probably have other issues that would dwarf this one. > >> How are you representing movnt in LLVM IR, with an intrinsic? > > Yes, it's an intrinsic inserted just before the load or store of > interest. > I'm not particularly happy with this solution because I'm not sure all > transformation passes will preserve the ordering of > intrinsic-followed-by-oper...

...lly wanted an alignment greater > than 1<<64, they would probably have other issues that would dwarf > this one. But see Evan's note. I can see a need for more bits if we take target-specific needs into account. I'll work on a solution. > >> How are you representing movnt in LLVM IR, with an intrinsic? > > > > Yes, it's an intrinsic inserted just before the load or store of > > interest. > > I'm not particularly happy with this solution because I'm not sure all > > transformation passes will preserve the ordering of > &gt...

...he !nontemporal attribute in LLVM, and the __builtin_nontemporal_* functions in Clang, is rather spartan and underspecified. In effect, it says the following things: * Atomic !nontemporal has no defined semantics * !nontemporal may use special instructions to save cache bandwidth, such as “MOVNT” on x86. What is crucially lacking from this specification is its effects in relation to other memory ordering constructs, namely fences. In lieu of text to the contrary, one could reasonably come to the conclusion that this code should be sufficient to generate correctly working code: store i64...

...viously doesn't specify things like how to create custom metadata kinds and all that jazz. As a few of us discussed at the latest dev meeting, I'd like to use custom metadata to annotate load/store instructions with "nontemporal" semantics to allow generation of instructions like MOVNT on x86-based targets. Losing the "nontemporal" annotation won't affect correctness so it seems a prime candidate for metadata. One question: should "nontemporal" be "native" metadata or "external?" -Dave

...w years. 3.1 added upgrade for: x86.sse2.pcmpeq.* - we have almost no test cases for this x86.sse2.pcmpgt.* - we no test cases for this x86.avx2.pcmpeq.* - we have no test cases x86.avx2.pcmpgt.* - we have no test cases for this x86.avx.vpermil.* - we do test this 3.2 added upgrade for: x86.avx.movnt.* - we have tests for this x86.xop.vpcom* - we have tests for this x86.sse41.ptest.* had its signature chagned and we upgrade from the old signature. We don't have tests for the old signature. x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't have any tests for the o...

...1, 2009, at 11:26 AM, David Greene wrote: > Right now the MemSDNode keeps a volatile bit in the SubclassData to > mark > volatile memory operations. > > We have some changes we'd like to push back that adds a NonTemporal > flag > to MemSDNode to mark instructions where movnt (on x86) and other > goodness > can happen (we'll also add the TableGen patterns to properly select > movnt). > > In our tree we simply added another flag to the MemSDNode constructor > and embedded it in SubclassData: > > MemSDNode(unsigned Opc, DebugLoc dl, SDVTLis...

On Tue, Jan 12, 2016 at 09:20:06AM -0800, Linus Torvalds wrote: > On Tue, Jan 12, 2016 at 5:57 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > #ifdef xchgrz > > /* same as xchg but poking at gcc red zone */ > > #define barrier() do { int ret; asm volatile ("xchgl %0, -4(%%" SP ");": "=r"(ret) :: "memory", "cc"); }

On Tue, Jan 12, 2016 at 09:20:06AM -0800, Linus Torvalds wrote: > On Tue, Jan 12, 2016 at 5:57 AM, Michael S. Tsirkin <mst at redhat.com> wrote: > > #ifdef xchgrz > > /* same as xchg but poking at gcc red zone */ > > #define barrier() do { int ret; asm volatile ("xchgl %0, -4(%%" SP ");": "=r"(ret) :: "memory", "cc"); }

...86.sse2.pcmpeq.* - we have almost no test cases for this > x86.sse2.pcmpgt.* - we no test cases for this > x86.avx2.pcmpeq.* - we have no test cases > x86.avx2.pcmpgt.* - we have no test cases for this > x86.avx.vpermil.* - we do test this > > 3.2 added upgrade for: > x86.avx.movnt.* - we have tests for this > x86.xop.vpcom* - we have tests for this > x86.sse41.ptest.* had its signature chagned and we upgrade from the old > signature. We don't have tests for the old signature. > x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't >...

...almost no test cases for this >> x86.sse2.pcmpgt.* - we no test cases for this >> x86.avx2.pcmpeq.* - we have no test cases >> x86.avx2.pcmpgt.* - we have no test cases for this >> x86.avx.vpermil.* - we do test this >> >> 3.2 added upgrade for: >> x86.avx.movnt.* - we have tests for this >> x86.xop.vpcom* - we have tests for this >> x86.sse41.ptest.* had its signature chagned and we upgrade from the old >> signature. We don't have tests for the old signature. >> x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. W...

....sse2.pcmpeq.* - we have almost no test cases for this > x86.sse2.pcmpgt.* - we no test cases for this > x86.avx2.pcmpeq.* - we have no test cases > x86.avx2.pcmpgt.* - we have no test cases for this > x86.avx.vpermil.* - we do test this > > 3.2 added upgrade for: > x86.avx.movnt.* - we have tests for this > x86.xop.vpcom* - we have tests for this > x86.sse41.ptest.* had its signature chagned and we upgrade from the old signature. We don't have tests for the old signature. > x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't have any...

...w years. 3.1 added upgrade for: x86.sse2.pcmpeq.* - we have almost no test cases for this x86.sse2.pcmpgt.* - we no test cases for this x86.avx2.pcmpeq.* - we have no test cases x86.avx2.pcmpgt.* - we have no test cases for this x86.avx.vpermil.* - we do test this 3.2 added upgrade for: x86.avx.movnt.* - we have tests for this x86.xop.vpcom* - we have tests for this x86.sse41.ptest.* had its signature chagned and we upgrade from the old signature. We don't have tests for the old signature. x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't have any tests for the o...

...86.sse2.pcmpeq.* - we have almost no test cases for this > x86.sse2.pcmpgt.* - we no test cases for this > x86.avx2.pcmpeq.* - we have no test cases > x86.avx2.pcmpgt.* - we have no test cases for this > x86.avx.vpermil.* - we do test this > > 3.2 added upgrade for: > x86.avx.movnt.* - we have tests for this > x86.xop.vpcom* - we have tests for this > x86.sse41.ptest.* had its signature chagned and we upgrade from the old > signature. We don't have tests for the old signature. > x86.xop.vfrcz.ss/sd had an argument dropped that we upgrade for. We don't >...