similar to: [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

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

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

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

Hello > Finally, I don't know how to describe following instructions in > MCoreInstrInfo.td, because of its variable ins/outs. Or what other files > should I use to finish this description? Do you need the isel support for them? If yes, then you should custom isel them. iirc ARM and SystemZ backends have similar instructions, while only the first one supports full isel for them. In

Suppose I have a target that does not have register+constant addressing mode. Then, I have DAG like: (store ..., (frameindex)) Targets like SPARC have the following patterns to catch this: def ADDRri : ComplexPattern<i32, 2, "SelectADDRri", [frameindex], []>; def STri : F3_2<3, 0b000100, (outs), (ins MEMri:$addr, IntRegs:$src),

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}",

Hi, all: Now I'm working on writing a backend for Moto MCore, but I don't know how to describe some instructions. First, I've already written MCoreRegisterInfo.td like these: class MCoreReg<bits<4> num, string name> : Register<name> { let Namespace = "MCore"; field bits<4> Num = num; } def R0 : MCoreReg< 0, "R0">,

On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > > Suppose I have a target that does not have register+constant > addressing mode. Then, I have DAG like: > > (store ..., (frameindex)) > > Targets like SPARC have the following patterns to catch this: > > def ADDRri : ComplexPattern<i32, 2, > "SelectADDRri", [frameindex], []>; > def STri :

Evan Cheng wrote: > > On Dec 3, 2007, at 12:53 PM, Vladimir Prus wrote: > >> >> Suppose I have a target that does not have register+constant >> addressing mode. Then, I have DAG like: >> >> (store ..., (frameindex)) >> >> Targets like SPARC have the following patterns to catch this: >> >> def ADDRri : ComplexPattern<i32, 2,

I'm trying to define a multiply-accumulate instruction for the LEON processor, a Subtarget of the Sparc target. The documentation for the processor is as follows: === To accelerate DSP algorithms, two multiply&accumulate instructions are implemented: UMAC and SMAC. The UMAC performs an unsigned 16-bit multiply, producing a 32-bit result, and adds the result to a 40-bit accumulator made

I've been looking to see if there's a way to get the instruction below (SMAC) emitted from a higher-level construct, but I'm starting to think this is unrealistic. To do so, I'd have to tie-in two other instructions: Firstly, clearing the ASR18 and Y register somewhere near the start of the method, then copying out the value of these registers somewhere near the end of the method,

Hi, I'm not sure. But in your lowered DAG the chain nodes are the first operands for you custom nodes, however for the other nodes the chain is the last operand. I seem to remember that during targetlowering the chain is the first operand and then it seems to switch over after ISelDAG, this confused me and may have something to do with the issue that you are seeing. I really don't

Hello all, I am adding a new target into LLVM. However there is a assembler for that target and I just want LLVM to generate assembly. I read the document "Writing an LLVM Backend". I am wondering to know whether I can ignore the Inst field in the following example: class InstSP<dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { field bits<32>

I'm a bit confused as to how some of the values in a Sparc store instruction actually come to be set. The Sparc backend defines a store as: def STri : F3_2<3, 0b000100, (outs), (ins MEMri:$addr, IntRegs:$src), "st $src, [$addr]", [(store IntRegs:$src, ADDRri:$addr)]>; F3_2 and it's superclasses are defined as follows:

Lu Mitnick <king19880326 at gmail.com> writes: > Hello all, > > I am adding a new target into LLVM. However there is a assembler for > that target and I just want LLVM to generate assembly. I read the > document "Writing an LLVM Backend". I am wondering to know whether I > can ignore the Inst field in the following example: I'm not an expert here so I'll

On Thu, Mar 21, 2013 at 2:26 PM, Jakob Stoklund Olesen <stoklund at 2pi.dk>wrote: > Currently, instruction selection patterns are defined like this: > > def : Pat<(and (not GR32:$src1), GR32:$src2), > (ANDN32rr GR32:$src1, GR32:$src2)>; > def : Pat<(and (not GR64:$src1), GR64:$src2), > (ANDN64rr GR64:$src1, GR64:$src2)>; > >

I have updated TableGen to support a new format for instruction selection patterns. Before: def : Pat<(subc IntRegs:$b, IntRegs:$c), (SUBCCrr IntRegs:$b, IntRegs:$c)>; After: def : Pat<(subc i32:$b, i32:$c), (SUBCCrr $b, $c)>; Since the pattern matching happens on a DAG with type labels, not register classes, I think it makes more sense to specify types directly on the input

Hi everyone, I have the following code (as part of a larger function): %0 = icmp eq i16 %a, 0 ; <i1> [#uses=1] br i1 %0, label %bb1, label %bb I would like to match this with a BRCOND, but all I get is an error message when compiling the above code that say: LLVM ERROR: Cannot yet select: 0x170f200: ch = br_cc 0x170f000, 0x170ed00, 0x170dc60, 0x170ec00, 0x170ef00 [ID=19]

On Fri, 2012-09-14 at 13:10 -0500, Will Schmidt wrote: > Hi all, > > I've been poking at AsmParser support for powerpc64 > (ppc64-elf-linux-abi) and have run into some behavior I don't understand > with the ptr_rc references coming out of the PPC*.td files when > generating the asm-matcher files. > > For instance : > $ ./build/bin/llvm-tblgen