similar to: [LLVMdev] Atomic ops cannot be built from C/OCaml bindings

I finally got around to adding these. The patch is posted in a pull request on my copy of llvm.git: https://github.com/jrk/llvm/pull/3 and a simple test with OCaml is here: https://gist.github.com/3948460 Feedback welcome. On Sep 14, 2012, at 7:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote: > Forgive me if I'm missing something obvious, but it seems that a >

How soon would I need to submit a patch for this for it to have a comfortable shot at making it into the 3.2 release? On Sep 14, 2012, at 8:05 PM, Eric Christopher <echristo at apple.com> wrote: > > On Sep 14, 2012, at 4:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote: > >> Is there a reason these should be omitted? > > Not in particular. Things are

On Sep 14, 2012, at 4:53 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu> wrote: > Is there a reason these should be omitted? Not in particular. Things are added to the C API as needed and usually on demand. -eric

I can't seem to find reference to intrinsics, beyond the is_intrinsic function. I am building a backend which needs to perform some target-specific code-generation (for SSE, AVX, and NEON), and intrinsics are the standard path in the C++ API.

I notice that there is not currently any intrinsic support for atomics in the PTX backend. Is this on the roadmap? Should it be as easy to add as it seems (plumbing through just like the thread ID instructions, &c.)? The obvious difference is that these ops have side effects. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type:

Looking further during down time at the dev meeting today, it actually seems that PTX atom.* and red.* intrinsics map extremely naturally onto the LLVM atomicrmw and cmpxchg instructions. The biggest issue is that a subset of things expressible with these LLVM instructions do not trivially map to PTX, and the range of things naturally supported depends on the features of a given target. With

On Fri, May 13, 2011 at 5:18 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu>wrote: > I can't seem to find reference to intrinsics, beyond the is_intrinsic > function. > > I am building a backend which needs to perform some target-specific > code-generation (for SSE, AVX, and NEON), and intrinsics are the > standard path in the C++ API. > What happens if you just

What is the current state of the JIT on Windows x64? I have noticed intermittent conversation about past incompatibility due to the calling convention idiosyncrasies, as well as some suggestion from last fall that it was targeted for a fix in the 2.5 timeframe, but see no definitive conclusion. Is this working in 2.5, in trunk, or likely to be in trunk soon?

Thanks, all. I didn’t realize a 7.0 RC was public and changed to 3.4—I will go down that road for now, though I’ll probably also look into integrating variants of the SPIR converter in the future. Another possibility is to skip libnvvm altogether and use LLVM's NVPTX target.  This is of course harder since you have to configure the passes yourself instead of just calling a few C

On Wed, Jun 3, 2009 at 6:29 PM, Jonathan Ragan-Kelley<jrk at csail.mit.edu> wrote: > What is the current state of the JIT on Windows x64? Broken; at the very least, there's http://llvm.org/bugs/show_bug.cgi?id=3739 . -Eli

From what I can tell, the truncstore paths all fail instruction selection in the current PTX backend. This is easy to work around for int types >= 16 bits by setting the truncstore action to expand in PTXISelLowering.cpp, but this cannot handle i8 values, since the PTX backend has no register representation for i8s. As a result of all this, it is not possible to store to i8 pointers at all.

This question is specifically motivated by the practical constraints of NVVM, but I don't know anywhere better to ask (hopefully, e.g., @jholewinski is still following), and I believe it concerns general LLVM issues: NVIDIA's libNVVM is built on LLVM 3.2. This means its bitcode and LL text parsers are from that generation. It's interface calls for adding modules as either bitcode

Loads (on ptx64) with an sext of a computed index operand fail instruction selection: LLVM ERROR: Cannot select: 0x7ff01401c210: i64,ch = load 0x10580e820, 0x7ff01401b510, 0x7ff01401b910<LD4[%memref1], sext from i32> [ID=8] 0x7ff01401b510: i64 = PTXISD::LOAD_PARAM 0x10580e820, 0x7ff01401b410 [ORD=2] [ID=6] 0x7ff01401b910: i64 = undef [ORD=4] [ID=3] This is for code of the form: %ptr

The OCaml bindings have been broken in trunk for a while. I chased it down to the addition of the Half type (rev 146786) not being reflected in the OCaml enums, causing mysterious type checking to break in the middle of the LLVM stack when using code generated from OCaml. The fix was trivial: https://github.com/jrk/llvm/pull/1/files -------------- next part -------------- A non-text attachment

Hello, I'm wondering how I can create an atomic load and add instruction for floating point values. If I use IRBuilder::CreateAtomicRMW() I get the error message: "atomicrmw operand must have integer type". I am using LLVM 3.4 and the only system I need to support is x86.

On Mon, Oct 31, 2011 at 3:15 PM, Jonathan Ragan-Kelley <jrk at csail.mit.edu>wrote: > I notice that there is not currently any intrinsic support for atomics in > the PTX backend. Is this on the roadmap? Should it be as easy to add as it > seems (plumbing through just like the thread ID instructions, &c.)? The > obvious difference is that these ops have side effects. > It

Hi All, With the "https://gcc.godbolt.org/z/yBYTrd" case . the atomic is converted to non atomic ops for x86 like from xchg dword ptr [100], eax to mov dword ptr [100], 1 the pass is responsible for this tranformation was instCombine i.e InstCombiner::visitAtomicRMWInst which converts the IR like %0 = atomicrmw xchg i32* inttoptr (i64 100 to i32*), i32 1 monotonic to store

On May 28, 2009, at 6:03 PM, Jonathan Ragan-Kelley wrote: > In the current trunk, System/Atomic.[h,cpp] define void > llvm::sys::MemoryFence(). This conflicts with the MemoryFence macro in > <windows.h> and (since it's a preprocessor macro, and not a scoped > function definition) causes the sys::MemoryFence definition on > Atomic.cpp:23 to explode, as it's

On 12/11/2015 01:29 PM, James Y Knight wrote: > > On Fri, Dec 11, 2015 at 3:05 PM, Philip Reames via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > >> One open question I don't know the answer to: Are there any >> special semantics required from floating point stores which >> aren't met

Yes, indeed. On May 28, 10:41 pm, Owen Anderson <resis... at mac.com> wrote: > > Wait, it defines MemoryFence() AND MemoryBarrier()?? > > Sheesh, they had to take all the reasonable names.  :-/