search for: jrk

.../nas/Mercredi/data/winserv/fserv/kluwer/Kluwer/ FinFisc/Common/XSD/.Werkzetel.xsd.XIjBum" -> "data/winserv/fserv/ kluwer/Kluwer/FinFisc/Common/XSD/Werkzetel.xsd": Permission denied (13) rsync: rename "/mnt/nas/Mercredi/data/winserv/fserv/kluwer/Kluwer/ FinFisc/Jaarrekening/Jrk/.Controledb.CDS.BVRfxd" -> "data/winserv/ fserv/kluwer/Kluwer/FinFisc/Jaarrekening/Jrk/Controledb.CDS": Permission denied (13) rsync: rename "/mnt/nas/Mercredi/data/winserv/fserv/kluwer/Kluwer/ FinFisc/Jaarrekening/Jrk/.F_VOL.fr3.grVTlP" -> "data/winserv/fser...

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

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 > number of core instruction...

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 added to the C API as needed and usually on demand. > > -eric

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?

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

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

...s 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 was scrubbed... Name: fix-ocaml-binding.patch Type: application/octet-stream Size: 1209 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20111228/94238980/attachment.obj>

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

...enerally, is there another accepted way to create NVVM programs from LLVM-based compilers which use versions more recent than 3.2? I can't imagine I'm the first one to run into this—3.2 is fairly old at this point, and NVVM seems wedded to its interface for stability reasons. Many thanks. -jrk -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150111/9e7e731e/attachment.html>

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.

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

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

Hi, My error isErro em hist.default(dados[[1]], freq = TRUE, seq(0, 30, 0.5), prob = FALSE, : some 'x' not counted; maybe 'breaks' do not span range of 'x' hist(dados[[1]],seq(0, 30, 0.5), prob=TRUE, xlab="chuva (mm/dia)",ylab="frequência", main="", cex.lab=1.6, cex.sub=3,cex.axis=3,cex.main=6) Someone help me? [[alternative

...m3P;hZ?Q z=H$f1X$n_UxthkcbgpJ_J&WtvoaJyemy<lMHRZe+C(Su+!AVQ*DBzAuxzUO{T66t! z?rg)IS8zvL?z)P*+Hw7APTF%v2kz*|9oKNuiL+}t{XM7GarYm%`v#uUg&Tk5^hQqq z#N9V>dNbGm%+*4k+Kn6CxlzQ^ZsD{iSBrW2t(@M*Gy3w3emt{;XZGirr95*0&%A?Y z4&<44^31z<=3jW`UwP)=jJCu`QH|fLJnL?r<>6U_d6t)FmGP`{o>jrKd_1d?XAR+5 zRXoejv+m(pLwQz!XI1m88lDy8S+$)0-3VzsJHoT;c=j-!J)CEc;Mw&&`yV{}pFI0t zJp11~`#(H;B+qUjJbM&iG++#1EMOd9JYWJ~B483=GGGc|DqtF5I$#FC!?R~1m<5;( zm;;y#sO9QBV*Fh-vMA44NO<ld!gCfAPL?2C3Rni(a-{#pu{GzeKrFy>Rw5Y6$zOQx zDrB!l%E!qX1T{Q&ErPo_K|gZWAzIFJ)}xvYNNyxN?_PwP0b7uDA7CrM%L#f+wg...

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