similar to: [LLVMdev] truncstore fails in PTX backend

Hi, Dan Someone on the irc suggest me using custom lowering to do the mapping correctly. But I am still trying to figure out how to do that. Regards, chenwj -- Wei-Ren Chen (陳韋任) Computer Systems Lab, Institute of Information Science, Academia Sinica, Taiwan (R.O.C.) Tel:886-2-2788-3799 #1667

On Thu, May 12, 2011 at 9:56 PM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, Dan > > Someone on the irc suggest me using custom lowering to do the mapping > correctly. But I am still trying to figure out how to do that. > Custom lowering means implementing the SelectionDAG instruction selection in the C++ class instead of the TableGen file. See PTXISelLowering.{h,cpp}

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:

Hi Justin, There are some backward incompatible features of PTX; for example, special registers are redefined as v4i32 (they were v4i16) in PTX 2.0. And CUDA 4.0 was rolled out last week. I heard that some instructions are deprecated. I am not sure how stable (or unstable) PTX specification is. Do you have a rough assessment of its stability? If PTX specification is still fast evolving, I would

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

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

Would there be any interest/opposition to extending the set of simple integer types in MVT to include the missing multiples of 8 (up to 64 bits)? That is: i24, i40, i48, i56? Adding the types to MVT (and ValueTypes.td) would allow LLVM to be targeted to architectures that have registers and operations of these sizes (for example, a 24-bit DSP that I'd like to develop a back end for has 24-,

Hi Justin, Is there any progress on new CUDA by llvm PTX? Cheers, Dan On 11 January 2013 07:57, 陳韋任 (Wei-Ren Chen) <chenwj at iis.sinica.edu.tw>wrote: > Hi Justin, > > I believe the PTX section in the link below need some love, > updating "lib/Target/PTX" to "lib/Target/NVPTX" for example. > Would you like to take a look? > >

I have an app that uses LLVM API calls from C++ to generate IR and JIT it for x86 (for subsequent live execution). I'm still using the old JIT, for what it's worth. I want to modify it (for prototype/experimental purposes for now) to JIT PTX (into a big string buffer?). Docs are sketchy. I can wade through it and figure it out by trial and error, but would be so very happy if somebody

There is no MCJIT support for PTX at the moment (mainly because PTX does not have a binary format, and is not machine code per se). To generate PTX at run-time, you just set up a standard codegen pass manager like you would like an off-line compiler. The output will be a string buffer that contains the PTX, which you can load into the CUDA runtime. As for determining if PTX support is compiled

On 1/11/2013 7:15 AM, Justin Holewinski wrote: > Removed from trunk. Pawel can decide if its necessary to update the > tarballs. > > Thanks for the report! Apparently git-svn does not delete removed > directories. PTX directories still exists in release_32 branch and RELEASE_32/final. But they are all empty so PTX can not be build. > > > On Fri, Jan 11, 2013 at 1:36

Hi I am interested to know: are there are any LLVM targets in the works for Nvidia's PTX ISA? Also if anyone knows about Ocelot (a project done by some students at my school): it does the opposite of what I am trying to do (translates PTX to LLVM IR to run Cuda kernels on the CPU). Thanks in advance. -Puyan

Hi everyone, I am trying to add some optimizations to LLVM's PTX backend. But i am unaware of the existing optimizations. Can you please guide me about the same? Thank You:) -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110903/bc038a07/attachment.html>

Hi, Dan I add "not" instruction support in PTXInstrInfo.td as you suggested before. multiclass PTX_LOGIC_2OP<string opcstr,PatFrag opnode> { ... } Now I am trying to write test case for logic and shift operations. But I have a trouble in mapping LLVM IR to PTX IR for "not" instruction. The test case I wrote is, define ptx_device i16 @t4_u16(i16 %x) { ; CHECK:

OK, fine -- an example of MCJIT that sets up for PTX JIT would also be helpful. On Dec 6, 2013, at 12:32 PM, Eli Bendersky <eliben at google.com> wrote: > > You'll have to switch to MCJIT for this purpose. Legacy JIT doesn't emit PTX. > > Eli -- Larry Gritz lg at larrygritz.com -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Sun, May 8, 2011 at 2:41 AM, 陳韋任 <chenwj at iis.sinica.edu.tw> wrote: > Hi, all > > I am trying to add "not" instruction support to PTX backend. > I add the line below in PTXInstrInfo.td, > > defm NOT : PTX_LOGIC<"not", not>; > > But I get errors below, > > >

Hi, Hope you've got this to work. LLVM IR is pretty low-level, much more so than PTX. As there are quite a few different ways to achieve the same thing in PTX, it's likely that we won't need to handle all of the different instructions for PTX as the IR will only support a subset of them. In the future, I would suggest putting together the test case first and only when the backend

Removed from trunk. Pawel can decide if its necessary to update the tarballs. Thanks for the report! Apparently git-svn does not delete removed directories. On Fri, Jan 11, 2013 at 1:36 AM, 陳韋任 (Wei-Ren Chen) < chenwj at iis.sinica.edu.tw> wrote: > Hi Pawel, > > PTX already be replaced with NVPTX. However, PTX subdirectory > still sit in lib/Target in 3.2 release. Do you

Right, I forgot to update that originally. I also have a separate document in the works that goes into more detail for NVPTX. On Fri, Jan 11, 2013 at 2:57 AM, 陳韋任 (Wei-Ren Chen) < chenwj at iis.sinica.edu.tw> wrote: > Hi Justin, > > I believe the PTX section in the link below need some love, > updating "lib/Target/PTX" to "lib/Target/NVPTX" for example.

On Fri, Dec 6, 2013 at 11:34 AM, Larry Gritz <lg at larrygritz.com> wrote: > I have an app that uses LLVM API calls from C++ to generate IR and JIT it > for x86 (for subsequent live execution). I'm still using the old JIT, for > what it's worth. > > I want to modify it (for prototype/experimental purposes for now) to JIT > PTX (into a big string buffer?). >