similar to: [LLVMdev] Compiling for several operand memories

Have not gotten much further on this, I can so far only use one memory with (for example) def LDr1 : F1< (outs GenRegs:$dst), (ins GenRegs:$addr), "ld*0* $dst, ($addr)", [(set GenRegs:$dst, (load GenRegs:$addr))],IIGenLoad>; and def LDrr : F1< (outs GenRegs:$dst), (ins MEMrr:$addr), "ld*0* $dst, ($addr)",

Hi all, I started to write an LLVM backend for custom CPU. I created XXXInstrInfo but there are some problems. I searched for it but I couldn't find anything. Can anyone help me? include "XXXInstrFormats.td" def simm16 : Operand<i32> { let DecoderMethod = "DecodeSimm16"; } def mem : Operand<i32> { let PrintMethod = "printMemOperand"; let

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>

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

Thanks Steve, I will try this out. I hadn’t realised that TableGen was restricted to matching instructions with more than one output operand. I’m assuming that this is only a limitation for inferring an instruction from the patterns, because it does seem to manage schedules okay. Curiously, my memory Reg32+Reg16 pattern is very similar to yours (the 16-bit offset is sign-extended though):

Thanks again for your help Steve, I’m thinking perhaps my “SelectADDRrr” pattern is inadequate. The sign-extension is at the hardware level, the code generator sees (should see) it as a 16-bit signed register value. My implementation is just: bool SHAVEISelDAGtoDAG::SelectADDRrr(SDValue &Addr, SDValue &Base, SDValue &Offset) { if ((Addr.getOpcode() == ISD::ADD) { Base

Jakob Stoklund Olesen wrote: > 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

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, I'm trying to implement __builtin_setjmp / __builtin_longjmp for Sparc processors. I think I'm very close, but I can't work out how to issue BuildMI-type instructions to load the address of the recovery location (set in setjmp) into a register using the SETHI / OR combination. I can't see any equivalent code anywhere else in Sparc. I imagine this is similar if I try to make a

I have an operation which loads a 16 bit block of data as 2 8-bit elements, sign extends the both parts to 32 bits and stores the result into 64-bit vector register. How can I define the pattern for this? just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] gives me error that extloav2i8 is not defined. (the same principle works for scalar sextload) So I need to define it

PPCTargetLowering::EmitInstrWithCustomInserter has a reference to the current MachineFunction for other purposes. Can you use MachineFunction::getRegInfo instead? Dan On Jul 8, 2008, at 1:56 PM, Gary Benson wrote: > Would it be acceptable to change MachineInstr::getRegInfo from private > to public so I can use it from > PPCTargetLowering::EmitInstrWithCustomInserter? > >

Hi Gary, This does not patch cleanly for me (PPCISelLowering.cpp). Can you prepare a updated patch? Thanks, Evan On Jul 10, 2008, at 11:45 AM, Gary Benson wrote: > Cool, that worked. New patch attached... > > Cheers, > Gary > > Evan Cheng wrote: >> Just cast both values to const TargetRegisterClass*. >> >> Evan >> >> On Jul 10, 2008, at 7:36

Just cast both values to const TargetRegisterClass*. Evan On Jul 10, 2008, at 7:36 AM, Gary Benson wrote: > Evan Cheng wrote: >> How about? >> >> const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : >> &PPC:G8RCRegClass; >> unsigned TmpReg = RegInfo.createVirtualRegister(RC); > > I tried something like that yesterday: > > const

Evan Cheng wrote: > How about? > > const TargetRegisterClass *RC = is64Bit ? &PPC:GPRCRegClass : > &PPC:G8RCRegClass; > unsigned TmpReg = RegInfo.createVirtualRegister(RC); I tried something like that yesterday: const TargetRegisterClass *RC = is64bit ? &PPC::GPRCRegClass : &PPC::G8RCRegClass; but I kept getting this error no matter how I arranged it:

You need to insert new basic blocks and update CFG to accomplish this. There is a hackish way to do this right now. Add a pseudo instruction to represent this operation and mark it usesCustomDAGSchedInserter. This means the intrinsic is mapped to a single (pseudo) node. But it is then expanded into instructions that can span multiple basic blocks. See

Would it be acceptable to change MachineInstr::getRegInfo from private to public so I can use it from PPCTargetLowering::EmitInstrWithCustomInserter? Cheers, Gary Evan Cheng wrote: > Look for createVirtualRegister. These are examples in > PPCISelLowering.cpp. > > Evan > On Jul 8, 2008, at 8:24 AM, Gary Benson wrote: > > > Hi Evan, > > > > Evan Cheng wrote:

Chris Lattner wrote: > On Jun 27, 2008, at 8:27 AM, Gary Benson wrote: > > def CMP_UNRESw : Pseudo<(outs), (ins GPRC:$rA, GPRC:$rB, i32imm: > > $label), > > "cmpw $rA, $rB\n\tbne- La${label}_exit", > > [(PPCcmp_unres GPRC:$rA, GPRC:$rB, imm: > > $label)]>; > > } > > > > ...and

I have a rudimentary implementation for load and store instructions, where the memory address operand is automatically post-incremented when the load or store instruction is issued. However, this is currently coded using custom lowering, and explicit pattern matching in the 'ISelDAGtoDAG' implementation. But it seems to me that I ought to be able to achieve this exclusively using

Hi Heikki, > just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] > > gives me error that extloav2i8 is not defined. I don't have a target to test this on, but looking at include/llvm/Target/TargetSelectionDAG.td, there is an "sextloadvi8" PatFrag, at least. I'd suggest a pattern along the lines of: (set V2I32Regs:$result, (v2i32 (sextloadvi8

On 10/30/2012 04:52 PM, Tim Northover wrote: > Hi Heikki, > >> just using [(set V2I32Regs:$result, (sextloadv2i8 ADDRrr:$address))] >> >> gives me error that extloav2i8 is not defined. > > I don't have a target to test this on, but looking at > include/llvm/Target/TargetSelectionDAG.td, there is an "sextloadvi8" > PatFrag, at least. I'd suggest