search for: membarri

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier" pattern isn't being found... but why? Thanks in advance, Gary -- http://gbenson.net/ -------------- next part -------------- Index: include/llvm/IntrinsicsPowerPC.t...

...wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > > 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, > > 0x10fa4be0". This presumably means my "membarrier" pattern > > isn't being found... but why? > > Because the i1's in the .bc file get promoted to i32 on ppc, > instead of i8. I...

...39;m trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch (attached) on the implementation in X86, but > >>>when I try and compile my test file (also attached) with llc I > >>>get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >>>0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, > >>>0x10fa4be0". This presumably means my "membarrier" pattern > >>>isn't being found... but why? > >> > >>Because the i1's in the .bc file get promoted...

Hi all, I want to implement llvm.memory.barrier on PowerPC. The implementation would be the single instruction "sync", but currently it's defined with: setOperationAction(ISD::MEMBARRIER, MVT::Other, Expand) in lib/Target/PowerPC/PPCISelLowering.cpp, which causes it to be a noop. I replaced the "Expand" with "Legal" in the hope I'd get an error message that'd point me to where I need to start adding stuff, but I just got the cryptic: Cannot yet se...

...n wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably > means my "membarrier" pattern isn't being found... but why? > > Thanks in advance, > Gary Because the i1's in the .bc file get promoted to i32 on ppc, instead of...

...>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test file (also attached) with llc I >>> get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier >>> 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, >>> 0x10fa4be0". This presumably means my "membarrier" pattern >>> isn't being found... but why? >> >> Because the i1's in the .bc file get promoted to i32 on ppc, >&g...

...to implement llvm.memory.barrier on PowerPC. I've >>>>> modelled my patch (attached) on the implementation in X86, but >>>>> when I try and compile my test file (also attached) with llc I >>>>> get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier >>>>> 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, >>>>> 0x10fa4be0". This presumably means my "membarrier" pattern >>>>> isn't being found... but why? >>>> >>>> Because the i1's in the .bc...

Attached is the target independent llvm.atomic.barrier support, as well as alpha and x86 (sse2) support. This matches Chandler's definitions, and the LangRef patch will just restore that. Non-sse2 barrier will be needed, I think it is "lock; mov %esp, %esp", but I'm not sure. Any objections? I'll take a hack at the front end support for __sync_synchronize after this

...vm-dev/2014-September/076701.html> where fences are exactly where they need to be, no more, no less. *Isn't x86's lfence just a no-op?* Yes, but we're proposing the addition of a target-independent non-temporal load barrier. It'll be up to the x86 backend to make it an X86ISD::MEMBARRIER and other backends to get it right (hint: it's not always a no-op). *Won't this optimization cause coherency misses? C++ access the thread stack concurrently all the time!* Maybe, but then it isn't much of an optimization if it's slowing code down. LLVM doesn't just target...

For reordering issues, it would be useful for llvm ir to provide various ways to control reordering. for example, a wrapper that indicates that other operations cannot be moved inside the wrapper. or a wrapper that indicates that the IR in it must be processed canonically. I think GCC may already have some of this but I'm not sure. On 04/17/2013 08:59 PM, Hal Finkel wrote: > -----

...tly where they need to be, no more, no less. > > > Isn't x86's lfence just a no-op? > > > Yes, but we're proposing the addition of a target-independent > > non-temporal load barrier. It'll be up to the x86 backend to make > > it > > an X86ISD::MEMBARRIER and other backends to get it right (hint: > > it's > > not always a no-op). > > > Won't this optimization cause coherency misses? C++ access the > > thread > > stack concurrently all the time! > > > Maybe, but then it isn't much of an opti...

...TAS a byte is sufficient, whereas with swap you probably would require that the exchange has machine-word size. > These implementations assume a very conservative interpretation. > result = __sync_fetch_and_add( <ty>* ptr, <ty> value ) > call void @llvm.atomic.membarrier( i1 true, i1 true, i1 true, > i1 true ) > %result = call <ty> @llvm.atomic.las( <ty>* %ptr, <ty> %value ) Shouldn't you have a second membar after the las() to be very conservative (i.e., if las() is supposed to really be linearizable)? Otherwise, th...

Hello, This is the second major revision of the atomic proposal for LLVM. I will try and give a brief overview of the motivating changes, but a greater portion of the text has changed, along with some changes to the proposed additions. http://chandlerc.net/llvm_atomics.html - The proposal has been rewritten to better delineate the goals and purposes of LLVM, and these additions to LLVM. The why

Torvald Riegel wrote: > Hi, > > I'd like to see support for something like this. I have some comments, and I > think there is existing work that you can reuse. "reuse within the compiler." > "While the processor may spin and attempt the atomic operation more than once > before it is successful, research indicates this is extremely uncommon." > I

...tly where they need to be, no more, no less. > > > > > > *Isn't x86's **lfence just a no-op?* > > > > Yes, but we're proposing the addition of a target-independent non-temporal > load barrier. It'll be up to the x86 backend to make it an > X86ISD::MEMBARRIER and other backends to get it right (hint: it's not > always a no-op). > > > > > > *Won't this optimization cause coherency misses? C++ access the thread > stack concurrently all the time!* > > > > Maybe, but then it isn't much of an optimization if...

...ese operations. 'cas' and 'swap' will lower to single byte instructions on x86 f.ex. > > These implementations assume a very conservative interpretation. > > result = __sync_fetch_and_add( <ty>* ptr, <ty> value ) > > call void @llvm.atomic.membarrier( i1 true, i1 true, i1 true, > > i1 true ) > > %result = call <ty> @llvm.atomic.las( <ty>* %ptr, <ty> %value ) > > Shouldn't you have a second membar after the las() to be very conservative > (i.e., if las() is supposed to really be linear...