similar to: [LLVMdev] how to define extending vector load patterns?

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

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>

Hello, My target has two data memories, each with its own load/store instructions but also has some instructions using both memories. I want to be able to access both memories in C-programs through the address space attribute. I have two ideas so far: Either: use two sets of addressing modes in InstrInfo.td: def ADDRrr_A : ComplexPattern<i16, 2, “SelectADDRrr_A", [], []>; def ADDRri :

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

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

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

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

Hi Quentin, >> Yes, the dags in view-isel-dags and view-legalize-types-dags are correct (the add operations are here and are their results are used) and the dags are the same. > > And what about view-sched-dags? The DAG looks like I described below (*) > This one should give you what has been selected. So if this is not correct, you have indeed a problem in the selection

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

My target machine uses the same 64-bit registers for integers and floating point. Do I have to specify a different register class for floating point that uses the same set of registers? Is there a target which does this I can copy? thanks, brian

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 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 Quentin, Am 03.11.2014 um 23:30 schrieb Quentin Colombet <qcolombet at apple.com>: >> Continuing at 4309 >> Match failed at index 4310 >> Continuing at 4322 >> Morphed node: 0x7fef2a033610: i32 = MVrr 0x7fef2a033610 [ORD=21] >> >> >> Does the add operation become a MOVE instruction, or is this a chain of rules? > > Yes, your add becomes

Hello David, Thanks for your example. Is that means that DAG pattern is consist of LLVM IR instruction?? I met an example [(set CPURegs:$dst, (OpNode CPURegs:$b, CPURegs:$c))] of MipsInstrInfo.td, but I can't find correspond LLVM IR instruction of "set" in "LLVM Language Reference Manual". Is that correspond to $dst = op $b, $c?? Would you mind to tell me whether there is

Hi, I'm implementing __builtin_setjmp and __builtin_longjmp for Sparc 32 bit processors (64 bit later, time allowing). I'm basing the code on the PowerPC version, which itself is based on the X86 version. This code is very nearly working, and I've had it working for -O0 optimisation (with a slightly different version to that below), so I know it's close. However, the PowerPC