search for: int32regs

...known limitation in the current implementation? If I have TableGen code like the following... 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; 1244 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0, Int32Regs:$dst1), 1246 (ins Int32Regs:$a), 1247 "test $dst0, $dst1, $a;", 1248 [(set Int32Regs:$dst0, Int32Regs:$dst1, (TestNode Int32Regs:$a))]>; ... TableGen crashes with the following stack trac...

...e outputs. > > > If I have TableGen code like the following... > > 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; > 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; > 1244 > 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0, Int32Regs:$dst1), > 1246 (ins Int32Regs:$a), > 1247 "test $dst0, $dst1, $a;", > 1248 [(set Int32Regs:$dst0, Int32Regs:$dst1, > (TestNode Int32Regs:$a))]>; > > ... TableGen crashes...

...le outputs. > > If I have TableGen code like the following... > > 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; > 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; > 1244 > 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0, Int32Regs:$dst1), > 1246 (ins Int32Regs:$a), > 1247 "test $dst0, $dst1, $a;", > 1248 [(set Int32Regs:$dst0, Int32Regs:$dst1, (TestNode Int32Regs:$a))]>; > > ... TableGen crashes with...

...gt; If I have TableGen code like the following... >> >> 1242 def SDTTestNode : SDTypeProfile<2, 1, [SDTCisSameAs<0, 1>]>; >> 1243 def TestNode : SDNode<"NVPTXISD::TestNode", SDTTestNode>; >> 1244 >> 1245 def MyTestNode : NVPTXInst<(outs Int32Regs:$dst0, Int32Regs:$dst1), >> 1246 (ins Int32Regs:$a), >> 1247 "test $dst0, $dst1, $a;", >> 1248 [(set Int32Regs:$dst0, Int32Regs:$dst1, (TestNode Int32Regs:$a))]>; >> >> ... T...

Hi Jacob, thank you for your reply. Your suggestion works! But instead of using the Pat<>, I am using def MOVE_ADDR : MYInst<(outs Int32Regs:$dst), (ins i32mem:$a), "move $dst, $a;", [(set Int32Regs:$dst, (Wrapper tglobaladdr:$a))]>; I don't quite understand what the semantics of Pat in general. Could you please explain what def : Pat<(BfinWrapper (i32 tglobaladdr:$addr)),...

...' and 'targetconstant', 'globaladdress' and 'targetglobaladdress'? It is not clear from the document when and which should be used. 2) On the processor I am working on, there is a 'move reg, mem_addr' instruction. When I try to match it using the pattern [(set Int32Regs::reg, tglobaladdr::mem_addr)]. the code generated by tblgen cannot be compiled because there will be a switch statement that contains two cases for the 'tglobaladdr', one is hard-coded in by tblgen and the other is generated by tbglen following the pattern I specified. The compilation fails...

...be changed further by the instruction selection. After instruction selection, everything should be converted to the target* variants. > 2) On the processor I am working on, there is a 'move reg, mem_addr' > instruction. > > When I try to match it using the pattern [(set Int32Regs::reg, > tglobaladdr::mem_addr)]. the code generated by tblgen cannot be > compiled because there will be a switch statement that contains two > cases for the 'tglobaladdr', one is hard-coded in by tblgen and the > other is generated by tbglen following the pattern I spec...

...as if it were a function. class F_SREG<string OpStr, NVPTXRegClass regclassOut, Intrinsic IntOp> : NVPTXInst<(outs regclassOut:$dst), (ins), OpStr, [(set regclassOut:$dst, (IntOp))]>; def INT_PTX_SREG_TID_X : F_SREG<"mov.u32 \t$dst, %tid.x;", Int32Regs, int_nvvm_read_ptx_sreg_tid_x>; This method of accessing intrinsics works just fine for other intrinsics (for instance sqrt). Should I be declaring these as extern global variables? Thanks, Timothy On Fri, Mar 1, 2013 at 12:44 PM, Dmitry Mikushin <dmitry at kernelgen.org>wrote: &gt...

..., NVPTXRegClass regclassOut, Intrinsic IntOp> : >            NVPTXInst<(outs regclassOut:$dst), (ins), >                              OpStr, >                  [(set regclassOut:$dst, (IntOp))]>; > > def INT_PTX_SREG_TID_X : F_SREG<"mov.u32 \t$dst, %tid.x;", Int32Regs, >    int_nvvm_read_ptx_sreg_tid_x>; > > This method of accessing intrinsics works just fine for other intrinsics > (for instance sqrt). Should I be declaring these as extern global > variables? > > Thanks, > > Timothy > > > On Fri, Mar 1, 2013 at 12:44...

...t; class F_SREG<string OpStr, NVPTXRegClass regclassOut, Intrinsic IntOp> : > NVPTXInst<(outs regclassOut:$dst), (ins), > OpStr, > [(set regclassOut:$dst, (IntOp))]>; > > def INT_PTX_SREG_TID_X : F_SREG<"mov.u32 \t$dst, %tid.x;", Int32Regs, > int_nvvm_read_ptx_sreg_tid_x>; > > This method of accessing intrinsics works just fine for other intrinsics > (for instance sqrt). Should I be declaring these as extern global variables? > > Thanks, > > Timothy > > > On Fri, Mar 1, 2013 at 12:44 PM, Dmitry M...

...OpStr, NVPTXRegClass regclassOut, Intrinsic IntOp> : > > NVPTXInst<(outs regclassOut:$dst), (ins), > > OpStr, > > [(set regclassOut:$dst, (IntOp))]>; > > > > def INT_PTX_SREG_TID_X : F_SREG<"mov.u32 \t$dst, %tid.x;", Int32Regs, > > int_nvvm_read_ptx_sreg_tid_x>; > > > > This method of accessing intrinsics works just fine for other intrinsics > > (for instance sqrt). Should I be declaring these as extern global > variables? > > > > Thanks, > > > > Timothy > > &...

Timothy, Those calls to compute grid intrinsics are definitely wrong. In ptx code they should end up into reading special registers, rather than function calls. Try to take some working example and figure out the LLVM IR differences between it and the result of your compiler. - D. ----- Original message ----- > I've written a compiler that outputs PTX code, the result seems fairly >

I've written a compiler that outputs PTX code, the result seems fairly reasonable, but I'm not sure the intrinsics are getting compiled correctly. In addition, when I try load the module using CUDA, I get an error: CUDA_ERROR_NO_BINARY_FOR_GPU. I'm running this on a 2012 MBP with a 640M GPU. PTX Code (for a mandelbrot calculation): // // Generated by LLVM NVPTX Back-End //