similar to: [LLVMdev] A few questions from a newbie

On 20/04/2009, at 07.35, Peter Bacon wrote: > Hello, I am learning to write a new backend for LLVM and have a few > simple questions. Hi Peter, I am a newbie too, but I have recently dealt with the same issues. > 1) What are the differences between 'constant' and 'targetconstant', > 'globaladdress' and 'targetglobaladdress'? It is not clear from

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

Hi, I am writing a backend for the Blackfin processor from Analog Devices. I just started so I still have a lot to learn about the code generator. So far, I can compile test/CodeGen/Generic/BasicInstrs.ll correctly, but that is about it. The Blackfin 32-bit registers divide naturally into several classes. I have modelled these register classes without knowing anything about what the code

On 1/15/2016 1:08 PM, Phil Tomson wrote: > > Ah, I see, the defm is a multi-class so I needed to change it to: > > def: Pat<(load (XSTGADDR_NORMAL tglobaladdr:$addr)), > (LOADI64_RI tglobaladdr:$addr, 0)>; > // Match load from a relocatable address to a load with GRP: > def: Pat<(load (XSTGADDR_USE_GRP tglobaladdr:$addr)), > (LOADI64_RI

On 1/15/2016 2:57 PM, Phil Tomson wrote: > > > I see the following in my SelectCode (in XSTGGenDGISel.inc): > > > /*2235*/ OPC_SwitchOpcode /*2 cases */, 27, > TARGET_VAL(XSTGISD::ADDR_NORMAL),// ->2266 > /*2239*/ OPC_RecordChild0, // #1 = $addr > /*2240*/ OPC_MoveChild, 0, > /*2242*/ OPC_CheckOpcode,

Hi, I am creating a new backend for a custom microcontroller. In order to create the backend I am modifying from Mips backend. My architecture has a store instruction with direct address mode. It accepts two arguments: source register and address (immediate). This instruction is not available in Mips, but it is in Hexagon, so I copied from Hexagon the following, adapting it to my registers: -

Are multi-output patterns in TableGen supposed to work, or is that a 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,

Thanks for the info. Is this on someone's list of things to do? On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> > wrote: > > Are multi-output patterns in TableGen supposed to work, or is that a known > limitation in the current implementation? >

On Jan 4, 2013, at 9:52 AM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Are multi-output patterns in TableGen supposed to work, or is that a known limitation in the current implementation? It is a known limitation. You have to write C++ code to match patterns with multiple outputs. > > If I have TableGen code like the following... > > 1242 def SDTTestNode

It has been something we've talked about for years, but I'm not aware of anyone working on it right now. On Jan 6, 2013, at 5:34 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > Thanks for the info. Is this on someone's list of things to do? > > > On Sun, Jan 6, 2013 at 7:41 PM, Bob Wilson <bob.wilson at apple.com> wrote: > > On Jan 4,

Hello Jim thanks for the reply, For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: def : Pat<(add DLDREGS:$src1, imm:$src2), (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>; Now, the typical pattern concerning additions with global addresses looks

Hello, I'm considering creating an LLVM backend for a 16 bit processor and modelling it around the (experimental) MSP430 back end. When reviewing MSP430InstrInfo.td I see def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; and can see in MSP430ISelLowering.cpp that ISD::GlobalAddress: ISD::BlockAddress: ISD::ExternalSymbol all get lowered to

On Thu, Jan 14, 2016 at 6:05 AM, Krzysztof Parzyszek < kparzysz at codeaurora.org> wrote: > On 1/13/2016 4:47 PM, Phil Tomson wrote: > >> >> First off, I got this idea from the LLVM Cookbook chapter 8: Writing an >> LLVM Backend: Lowering to multiple instructions. (now I'm having my >> doubts as to whether this is the right approach) >> > >

On Apr 26, 2011, at 1:27 PM, Borja Ferrer wrote: > Hello Jim thanks for the reply, > > For normal additions with immediates I've done the same as ARM does, basically transforming add(x, imm) nodes to sub(x, -imm) with a pattern in the .td file like this: > def : Pat<(add DLDREGS:$src1, imm:$src2), > (SUBIWRdK DLDREGS:$src1, (imm16_neg_XFORM imm:$src2))>;

Thanks Jim, I've implemented the negation part successfully :) maybe the second part could be a possible feature request so others could use it aswell? 2011/4/27 Jim Grosbach <grosbach at apple.com> > > On Apr 26, 2011, at 1:27 PM, Borja Ferrer wrote: > > > Hello Jim thanks for the reply, > > > > For normal additions with immediates I've done the same as

On 25/07/12 18:21, Richard Osborne wrote: > On 25 Jul 2012, at 04:49, Paul Shortis wrote: > > >> Hello, >> >> I'm considering creating an LLVM backend for a 16 bit processor and >> modelling it around the (experimental) MSP430 back end. >> >> When reviewing MSP430InstrInfo.td I see >> >> def MSP430Wrapper :

On 25 Jul 2012, at 04:49, Paul Shortis wrote: > Hello, > > I'm considering creating an LLVM backend for a 16 bit processor and > modelling it around the (experimental) MSP430 back end. > > When reviewing MSP430InstrInfo.td I see > > def MSP430Wrapper : SDNode<"MSP430ISD::Wrapper", SDT_MSP430Wrapper>; > > and can see in MSP430ISelLowering.cpp

On Wed, Jan 13, 2016 at 2:08 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 1/13/2016 2:26 PM, Phil Tomson via llvm-dev wrote: > >> I've got this PseudoOp defined: >> >> def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; >> def XSTGRELADDR :

I've got this PseudoOp defined: def SDT_RELADDR : SDTypeProfile<1, 2, [SDTCisInt<0>, SDTCisInt<1>]>; def XSTGRELADDR : SDNode<"XSTGISD::RELADDR", SDT_RELADDR>; let Constraints = "$dst = $addr" in { //, Uses= [GRP] in { def RelAddr : XSTGPseudo< (outs GPRC:$dst), (ins i64imm:$spoff,

Hi, I've been hitting my head to wall two days now. This is practically my first contact with InstrInfo.td files. Is there any tutorial how to make this kind of stuff? Or should I just keep on studying Sparc and other backends? So I added new intrinsic to llvm/include/llvm/TCEInstrinsics.td: def int_tce_customop : Intrinsic<[llvm_void_ty, llvm_ptr_ty, llvm_vararg_ty], [],