similar to: [LLVMdev] Fix for 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

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

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

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

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.

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

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?

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

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

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

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

I've isolated a bug in SSE codegen to the attached example. define void @f(<2 x float>* %in, <2 x double>* %out) { entry: %0 = load <2 x float>* %in, align 8 %1 = fpext <2 x float> %0 to <2 x double> store <2 x double> %1, <2 x double>* %out, align 1 ret void } The code should load a <2 x float> vector from %in, fpext cast it to

Hello everyone! I'm having strange errors backuping with rsync. I backup over a samba share mounted using mount_smbfs on freebsd. The first backup is no problem, no errors just all data transferred (Speedup 1.00). The second backup seems more problematic here is the error: rsync: failed to set times on "/mnt/nas/Mercredi/data": Bad file descriptor (9) rsync: failed to set

I am running a regression: ols.reg1 <- lm(y ~ x1 + x2 + x3 + x4) on a data.frame and then generating fitted values: y.hat <- ols.reg1$fitted.values Then I would like to add these fitted values to the data.frame as a new variable. The problem is that when the values are predicted the resulting output has too few rows. for some reason certian observations do not get predicted values. So

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