similar to: [LLVMdev] [LLVMDev] Add not instruction to PTX backend

Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] [LLVMDev] Add not instruction to PTX backend"

2011 May 08
0
[LLVMdev] [LLVMDev] Add not instruction to PTX backend
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, > > >
2011 May 09
3
[LLVMdev] [LLVMDev] Add not instruction to PTX backend
Hi, Justin > We're been writing multiclasses for each unique type of instruction. The > current PTX_LOGIC version is for 3-operand instructions. A new multiclass > needs to be created for 2-operand logic instructions. I am trying to add a multiclass for 2-operand logic instructions. For example, multiclass PTX_LOGIC_2OP<string opcstr, SDNode opnode> { def ripreds :
2011 May 09
0
[LLVMdev] [LLVMDev] Add not instruction to PTX backend
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> 陳韋任 wrote: <blockquote cite="mid:20110509013918.GA13760@cs.nctu.edu.tw" type="cite">
2011 May 11
3
[LLVMdev] [LLVMDev] Add not instruction to PTX backend
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:
2006 Oct 02
0
[LLVMdev] Instruction descriptions question
On Sun, 1 Oct 2006, Roman Levenstein wrote: > I'm trying to implement a new backend for an embedded CISC processor. > Therefore I thought that it makes sense to take X86 target as a basis, > to save some time. Ok. Note that the X86 backend is one of the most complex though, because it supports several subtargets and ABIs, which makes it more complex than some other targets. >
2007 Oct 19
0
[LLVMdev] Adding address registers to back-end
On Oct 19, 2007, at 8:15 AM, Boris Boesler wrote: > Hi! > > I'm writing a new back-end for a new architecture. First, I'll do > some "tests" with an existing back-end (I chose the Sparc back-end). > My architecture has special address-registers and I want to add such > new address-registers to my Sparc back-end. > > 1) I defined a new register call
2012 Apr 19
2
[LLVMdev] Tablegen to match a literal in an instruction
I am trying to make some modifications to our code generator that will produce better code, but require adding new patterns. What I am trying to do is take a register/register pattern and change it to a register/immediate. So for example, I have this pattern: class ILFormat<ILOpCode op, dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { let Namespace =
2012 Apr 19
3
[LLVMdev] Tablegen to match a literal in an instruction
I'm not at the machine that has the changes, but it was failing at index 0. Micah From: Owen Anderson [mailto:resistor at mac.com] Sent: Thursday, April 19, 2012 3:35 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Tablegen to match a literal in an instruction Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output
2012 Apr 19
0
[LLVMdev] Tablegen to match a literal in an instruction
Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output from llc -debug, and matching it up with the state machine in your DAGISel.inc to see at what step the auto-generated matcher is failing to match your and-with-immediate? -Owen On Apr 19, 2012, at 3:07 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > I am trying to make
2007 Oct 21
1
[LLVMdev] Adding address registers to back-end
Hi! >> I'm writing a new back-end for a new architecture. First, I'll do >> some "tests" with an existing back-end (I chose the Sparc back-end). >> My architecture has special address-registers and I want to add such >> new address-registers to my Sparc back-end. >> .... >> The GlobalAddress for variable c is replaced by an ADD(HI(c), LO
2006 Oct 01
2
[LLVMdev] Instruction descriptions question
Hi, I'm trying to implement a new backend for an embedded CISC processor. Therefore I thought that it makes sense to take X86 target as a basis, to save some time. But when I look into the X86InstrInfo.td, I have a very strong feeling that it is one of the most complex instruction set descriptions compared to other targets. I can imagine that this is due to the complexity of X86's
2012 Apr 19
0
[LLVMdev] Tablegen to match a literal in an instruction
Right, it's failing when it tries to materialize a move of a constant into a register. But it's only trying to do that because it previously failed to fold the constant into the AND. What you need to do is step through the path it takes when matching the AND node, and try to figure out why it ends up selecting the register-register version rather than the register-immediate version.
2009 Feb 10
0
[LLVMdev] Multiclass patterns
On Tue, Feb 10, 2009 at 8:27 AM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Bill, > Sorry if I wasn't clear enough. I wasn't referring to multiclass's that > define other classes, but with using patterns inside of a multiclass to > reduce redundant code. > For example: > multiclass IntSubtract<SDNode node> > { > def _i8 : Pat<(sub
2009 Mar 24
2
[LLVMdev] Reducing .td redundancy
Is it legal to do something like a !strconcat on a non-string entity? That is, is there some operation that will let me do this (replace SOME_CONCAT with an appropriate operator): (WARNING! Hacked-up tablegen ahead!) multiclass sse_fp_binop_bitwise_rm<bits<8> opc, string OpcodeStr, SDNode OpNode> { // Vector operation emulating scalar (fp)
2007 Oct 19
2
[LLVMdev] Adding address registers to back-end
Hi! I'm writing a new back-end for a new architecture. First, I'll do some "tests" with an existing back-end (I chose the Sparc back-end). My architecture has special address-registers and I want to add such new address-registers to my Sparc back-end. 1) I defined a new register call AddrRegs 2) I registered the class AddrRegs (addRegisterClass(MVT::iPTR, .. )) 3) I
2011 Nov 22
2
[LLVMdev] PTX builtin functions.
Alberto, The AMDIL backend solves your problem with intrinsic overloading this way: def int_AMDIL_mad : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; Where TernaryIntFloat is defined as: class TernaryIntFloat : Intrinsic<[llvm_anyfloat_ty], [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>], []>; This allows us to write a
2011 Dec 05
0
[LLVMdev] PTX builtin functions.
On Sun, Dec 4, 2011 at 1:10 PM, Alberto Magni <alberto.magni86 at gmail.com>wrote: > Hi Justin, > > sorry for the delay, I have been busy. > > Micah's proposal requires to move the definitions of the intrinsics > from include/llvm/IntrinsicsPTX.td to lib/Target/PTX/PTXIntrinsics.td > thus allowing the generation of the file PTXGenIntrinsics.inc which > will be
2006 Oct 02
2
[LLVMdev] Instruction descriptions question
Hi Chris, Thanks a lot for your answer! Chris Lattner wrote: >> 1. Why does X86 instruction set description provide different >> descriptions for the same instructions, which differ only in the size >> of operands? >> E.g. >> >> def MOV8rm : I<0x8A, MRMSrcMem, (ops GR8 :$dst, i8mem :$src), >> "mov{b} {$src, $dst|$dst, $src}",
2011 Nov 23
0
[LLVMdev] PTX builtin functions.
On Tue, Nov 22, 2011 at 5:01 PM, Villmow, Micah <Micah.Villmow at amd.com> wrote: > Alberto, >  The AMDIL backend solves your problem with intrinsic overloading this way: > def int_AMDIL_mad     : GCCBuiltin<"__amdil_mad">, TernaryIntFloat; > > Where TernaryIntFloat is defined as: > class TernaryIntFloat : >          Intrinsic<[llvm_anyfloat_ty],
2011 Dec 08
0
[LLVMdev] PTX builtin functions.
On Thu, Dec 8, 2011 at 11:36 AM, Villmow, Micah <Micah.Villmow at amd.com>wrote: > It is my understanding that all you need to do is specify let isTarget = > 1 in your .td file and it will generate target specific intrinsics. This > should allow you to keep the IntrinsicsPTX.td file in the same location. > So we keep the intrinsics defined in include/llvm/IntrinsicsPTX.td?