similar to: [LLVMdev] Adding intrinsic with variable argument list HOWTO.

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/07/12 12:14, Paul Shortis wrote: > Thanks Richard, > > You're correct, they are similar. In the XCoreInstrInfo.td patterns > what I'm struggling with is why this .... > > def BL_lu10 : _FLU10< > (outs), > (ins calltarget:$target, variable_ops), > "bl $target", >

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

Hello, This bug affects all LLVM versions from 2.6 to trunk : http://llvm.org/bugs/show_bug.cgi?id=5081 The workaround I found is to add this : Index: lib/Target/X86/X86Instr64bit.td =================================================================== --- lib/Target/X86/X86Instr64bit.td (revision 105882) +++ lib/Target/X86/X86Instr64bit.td (working copy) @@ -1832,6 +1832,8 @@

Hi, I was talking with aKor in #llvm how we could implement custom operation support for our ASIP architecture. We came into solution that the best way would be to write new custom operation intrinsic and optimization pass for raising certain type of function calls to those intrinsics (similar to raising mallocs). Basically our custom operation are like calls, with operand name and multiple

On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > Hello, > > This bug affects all LLVM versions from 2.6 to trunk : > http://llvm.org/bugs/show_bug.cgi?id=5081 > > The workaround I found is to add this : > > Index: lib/Target/X86/X86Instr64bit.td > =================================================================== > --- lib/Target/X86/X86Instr64bit.td

On 06/21/2010 08:21 PM, Eric Christopher wrote: > On Jun 21, 2010, at 2:56 AM, Patrick Marlier wrote: > > >> Hello, >> >> This bug affects all LLVM versions from 2.6 to trunk : >> http://llvm.org/bugs/show_bug.cgi?id=5081 >> >> The workaround I found is to add this : >> >> Index: lib/Target/X86/X86Instr64bit.td >>

<table cellspacing='0' cellpadding='0' border='0' ><tr><td style='font: inherit;'>Hi,<br>I tried creating intrinsics which are to be<br>placeholders for a set of instructions (actually a section of a basic block) to be executed elsewhere(for e.g. in HW).<br>These intrinsics are to take care of the data dependencies of the set of

On Tue, 31 Jul 2007, [ISO-8859-1] Mikael Lepist� wrote: > I was talking with aKor in #llvm how we could implement custom operation > support for our ASIP architecture. We came into solution that the best > way would be to write new custom operation intrinsic and optimization > pass for raising certain type of function calls to those intrinsics > (similar to raising mallocs). >

> From: Mikael Lepist? <mikael.lepisto at tut.fi> > > Hi, Hi Mikael > I was talking with aKor in #llvm how we could implement custom operation > support for our ASIP architecture. We came into solution that the best > way would be to write new custom operation intrinsic and optimization > pass for raising certain type of function calls to those intrinsics > (similar

Hello, LLVM's intrinsic overloading mechanism does not currently support overloading on pointer types. Patches to implement this would be welcome. Dan On May 7, 2008, at 9:25 AM, aditya vishnubhotla wrote: > Hi, > I tried creating intrinsics which are to be > placeholders for a set of instructions (actually a section of a > basic block) to be executed elsewhere(for e.g. in

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

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

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

Hello, I am learning to write a new backend for LLVM and have a few simple questions. 1) What are the differences between 'constant' 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

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

The ARM Neon load, store and shuffle operations that I've been implementing recently with LLVM intrinsics do not care about the distinction between vectors with i32 and f32 elements -- only the size matters. But, because we have only MVT::fAny and MVT::iAny types, I've been having to define separate intrinsics for the operations with floating-point vector elements. It