similar to: [LLVMdev] Windows x64 JIT usability

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

Forgive me if I'm missing something obvious, but it seems that a number of core instructions—I'm specifically running in to `atomicrmw`, `fence`, and `cmpxchg` at the moment—cannot be constructed from the C bindings, and are therefore also inaccessible to the OCaml bindings. There are opcodes for each of these in the llvm-c/Core.h, but there seems to be no way to construct them. Is there

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

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 >

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.

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 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

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

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

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.

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:

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

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

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

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

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.  :-/

Slightly off-topic, but I imagine this crowd must have some experience using Xcode 4 for projects linking to LLVM. I've actually started using Xcode 4 as an IDE for C/C++ development thanks to the vastly improved code analysis-based tools it's inherited largely thanks to LLVM. But, ironically, I am particularly struggling to get the tools to parse and analyze LLVM (as a client, not for

On Jun 1, 2009, at 11:17 PM, Jonathan Ragan-Kelley wrote: > Yes, indeed. Are they macros or functions? If macros, why not just #undef them at the top of Atomics.h? -Chris > > > 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

Jonathan Ragan-Kelley <katokop1 <at> gmail.com> writes: > > Slightly off-topic, but I imagine this crowd must have some experience > using Xcode 4 for projects linking to LLVM. I've actually started > using Xcode 4 as an IDE for C/C++ development thanks to the vastly > improved code analysis-based tools it's inherited largely thanks to > LLVM. But,

Building on OS X 10.7.1 with the standard toolchain, I have seen the following linker warnings going back a number of versions in trunk whenever I build an executable linked with LLVM: ld: warning: direct access in llvm::fouts() to global weak symbol llvm::formatted_raw_ostream::~formatted_raw_ostream() means the weak symbol cannot be overridden at runtime. This was likely caused by