similar to: Nontemporal memory accesses and fences

________________________________ From: llvm-dev <llvm-dev-bounces at lists.llvm.org> on behalf of JF Bastien via llvm-dev <llvm-dev at lists.llvm.org> Sent: Tuesday, April 28, 2020 4:54 PM To: Cranmer, Joshua <joshua.cranmer at intel.com> Cc: llvm-dev at lists.llvm.org <llvm-dev at lists.llvm.org> Subject: Re: [llvm-dev] Nontemporal memory accesses and fences I see

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

Is there some documentation about metadata and how to use it somewhere? The doxygen-generated stuff obviously 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

On Jul 31, 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

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"); }

On Thu, Jan 14, 2016 at 1:35 PM, David Majnemer <david.majnemer at gmail.com> wrote: > > > On Thu, Jan 14, 2016 at 1:13 PM, JF Bastien <jfb at google.com> wrote: > >> On Thu, Jan 14, 2016 at 1:10 PM, David Majnemer via llvm-dev < >> llvm-dev at lists.llvm.org> wrote: >> >>> >>> >>> On Wed, Jan 13, 2016 at 7:00 PM, Hans

On Thu, Jan 14, 2016 at 1:10 PM, David Majnemer via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Wed, Jan 13, 2016 at 7:00 PM, Hans Boehm via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I agree with Tim's assessment for ARM. That's interesting; I wasn't >> previously aware of that instruction. >> >> My

I agree with Tim's assessment for ARM. That's interesting; I wasn't previously aware of that instruction. My understanding is that Alpha would have the same problem for normal loads. I'm all in favor of more systematic handling of the fences associated with x86 non-temporal accesses. AFAICT, nontemporal loads and stores seem to have different fencing rules on x86, none of them

On Jan 4, 2010, at 3:14 PM, David Greene wrote: > Is there some documentation about metadata and how to use it > somewhere? > The doxygen-generated stuff obviously doesn't specify things like how > to create custom metadata kinds and all that jazz. The metadata design and APIs are still evolving. I wouldn't recommend building anything on it just yet, but I'm hoping it

On Wed, Jan 13, 2016 at 10:32 AM, John Brawn <John.Brawn at arm.com> wrote: > *What about non-x86 architectures?* > > > > Architectures such as ARMv8 support non-temporal instructions and require > barriers such as DMB nshld to order loads and DMB nshst to order stores. > > > > Even ARM's address-dependency rule (a.k.a. the ill-fated >

Hello, fencing enthusiasts! *TL;DR:* We'd like to propose an addition to the LLVM memory model requiring non-temporal accesses be surrounded by non-temporal load barriers and non-temporal store barriers, and we'd like to add such orderings to the fence IR opcode. We are open to different approaches, hence this email instead of a patch. *Who's "we"?* Philip Reames brought

Hi JF, Philip, Clang currently has __builtin_nontemporal_store and __builtin_nontemporal_load. How will the usage model for those change? Thanks again, Hal ----- Original Message ----- > From: "Philip Reames via llvm-dev" <llvm-dev at lists.llvm.org> > To: "JF Bastien" <jfb at google.com>, "llvm-dev" > <llvm-dev at lists.llvm.org> >

On Thursday 11 February 2010 17:40:24 David Greene wrote: > While hacking around in the SelectionDAG build code, I've made the > isVolatile, (new) isNonTemporal and Alignment parameters to > SelectionDAG::getLoad/getStore and friends non-default. > > I've already caught one bug in the XCore backend by doing this: > > if (Offset % 4 == 0) { > // We've

On Fri, Feb 12, 2010 at 1:43 PM, David Greene <dag at cray.com> wrote: > On Thursday 11 February 2010 17:40:24 David Greene wrote: >> While hacking around in the SelectionDAG build code, I've made the >> isVolatile, (new) isNonTemporal and Alignment parameters to >> SelectionDAG::getLoad/getStore and friends non-default. >> >> I've already caught one

I also want a way to add target specific flag to a SDNode (which should be transferred to MachineInstr). For example, on x86 lots of opcodes have *lock* variants. Right now, these are separate instructions. I'd prefer to make it into a target specific flag that can be toggled by some sort of post-isel action routine. One way to handle this might be to expand the use of SubclassData.

On 01/14/2016 04:05 PM, Hans Boehm via llvm-dev wrote: > > > On Thu, Jan 14, 2016 at 1:37 PM, JF Bastien <jfb at google.com > <mailto:jfb at google.com>> wrote: > > On Thu, Jan 14, 2016 at 1:35 PM, David Majnemer > <david.majnemer at gmail.com <mailto:david.majnemer at gmail.com>> wrote: > > > > On Thu, Jan 14, 2016 at 1:13

On Thursday 11 February 2010 14:05:21 David Greene wrote: > Either ParseLoad and probably other instructions need to look for metadata > explicitly or ParseOptionalCommaAlign needs to know about general metadata. > > My inkling is to fix ParseOptionalCommaAlign. Sound reasonable? Well, that's a rat's nest. I backed up and thought maybe I have the metadata syntax wrong. So

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 did

While hacking around in the SelectionDAG build code, I've made the isVolatile, (new) isNonTemporal and Alignment parameters to SelectionDAG::getLoad/getStore and friends non-default. I've already caught one bug in the XCore backend by doing this: if (Offset % 4 == 0) { // We've managed to infer better alignment information than the load // already has. Use an aligned