similar to: [LLVMdev] problems with tablegen and namespaces

On Mon, 1 May 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to write a skeleton of an ARM back end. I have declared > the following class > > class InstARM<dag ops, string asmstr, list<dag> pattern> : Instruction { > let Namespace = "ARM"; > > dag OperandList = ops; > let AsmString = asmstr; > let Pattern = pattern; > } > > and

The macro $src, $dest used in Instruction::AsmString must be "declared" in Instruction::OperandList, right? $$ has special meaning? On 5/6/05, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 6 May 2005, Tzu-Chien Chiu wrote: > > llvm/lib/Target/X86/X86InstrInfo.td: > > class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string > >

llvm/lib/Target/X86/X86InstrInfo.td: class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string AsmStr> : Instruction { .... dag OperandList = ops; string AsmString = AsmStr; } def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), "mov{l} {$src, $dst|$dst, $src}">; I cannot find any document on initializing the

On Fri, 6 May 2005, Tzu-Chien Chiu wrote: > llvm/lib/Target/X86/X86InstrInfo.td: > class X86Inst<bits<8> opcod, Format f, ImmType i, dag ops, string > AsmStr> : Instruction { > .... > dag OperandList = ops; > string AsmString = AsmStr; > } > > def MOV32mi : Ii32<0xC7, MRM0m, (ops i32mem:$dst, i32imm:$src), > "mov{l}

> > In ARMGenInstrNames.inc, the TargetInstrInfo namespace is used if the > > AAA instruction isn't defined and the ARM namespace is used if it is > > defined. > > I don't follow here. XXXGenInstrNames.inc shouldn't have namespaces at > all. Can you paste a few lines out of the file that you are seeing? Sure: with AAA defined, ARMGenInstrNames.inc looks

On Apr 18, 2007, at 2:07 PM, Evan Cheng wrote: > > On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > >> I noticed that the TableGen code emitter generator assumes that >> the instruction fields are declared in the instruction format in >> the same order that operands are defined. This seems like a bad >> dependence to me, and that TableGen should match

Hi all, I am trying to implement an instruction with no operand for example "clr" in TableGen. ----------------------------------------- e.g. *InstrInfo.td:* class TestInst<string opc, string asmstr, dag oops, dag iops, list<dag> pattern> : Instruction { ... } def int_no_operand : Intrinsic<[]>; class ALU<string opc> : TestInst<opc,

> Okay, if you update from CVS, this problem should be fixed, at least for > the AsmPrinter. Please try it out (without AAA), and let me know if you > have problems with any other part of the code generator. The behaviour now is: The TargetInstrInfo namespace is used for the PHI instruction regardless of the presence of the AAA instruction. In ARMGenInstrNames.inc, the TargetInstrInfo

> This looks like a tblgen bug. If you look at > utils/TableGen/AsmWriterEmitter.cpp:290, it appears to take the namespace > from the first instruction in an equivalence class that it comes across. > I will fix this bug this afternoon, but in the meantime, if you define an > instruction "AAA" which takes no operands, it will work around this. Thanks. Defining

On Mon, 1 May 2006, [UTF-8] Rafael Esp?ndola wrote: >> Okay, if you update from CVS, this problem should be fixed, at least for >> the AsmPrinter. Please try it out (without AAA), and let me know if you >> have problems with any other part of the code generator. > The behaviour now is: > The TargetInstrInfo namespace is used for the PHI instruction > regardless of the

I am trying to make some modifications to our code generator that will produce better code, but require adding new patterns. What I am trying to do is take a register/register pattern and change it to a register/immediate. So for example, I have this pattern: class ILFormat<ILOpCode op, dag outs, dag ins, string asmstr, list<dag> pattern> : Instruction { let Namespace =

class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern, InstrItinClass itin> : // ... This class has template args. You don't specify them in the first template arg of class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>: // ... --Sean Silva On Tue, Jul 3, 2012 at 2:29 PM, reed kotler <rkotler at mips.com> wrote: > Not sure what you mean.

I think that what I did originally should have worked and the bug was correct as I reported it. Here is an alternate implementation which has the same problem. class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, !cast<FRRR16_ins>(I).OutOperandList, !cast<FRRR16_ins>(I).InOperandList,

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>

Not sure what you mean. I.OutOperandList == (outs CPU16Regs:$rx) I.InOperandList == (ins CPU16Regs:$ry, CPU16Regs:$rz) On 07/02/2012 09:26 PM, Sean Silva wrote: > I think you're missing the template args for `FRRR16_ins` in the first > argument. The switch in TGParser::ParseType() doesn't cover the case > of types with template args though... which makes me wonder what is

I've filed the following bug. Maybe I'm doing something stupid here or maybe someone knows of a workaround. The following fragment from mips16 (not yet checked into main source). The problem is that I should be able to pass parameters: I.OutOperandList, I.InOperandList But instead, I must back substitute what I know the values of these are. (outs CPU16Regs:$rx), (ins CPU16Regs:$ry,

Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output from llc -debug, and matching it up with the state machine in your DAGISel.inc to see at what step the auto-generated matcher is failing to match your and-with-immediate? -Owen On Apr 19, 2012, at 3:07 PM, "Villmow, Micah" <Micah.Villmow at amd.com> wrote: > I am trying to make

This variant works: class ArithLogicRTest16<string I, SDNode OpNode, bit isComm = 0>: FRRR16<!cast<FRRR16_ins>(I).f, (outs CPU16Regs:$rx), (ins CPU16Regs:$ry, CPU16Regs:$rz), // !cast<FRRR16_ins>(I).OutOperandList, // !cast<FRRR16_ins>(I).InOperandList, !cast<FRRR16_ins>(I).AsmString, [(set CPU16Regs:$rx,

I'm not at the machine that has the changes, but it was failing at index 0. Micah From: Owen Anderson [mailto:resistor at mac.com] Sent: Thursday, April 19, 2012 3:35 PM To: Villmow, Micah Cc: LLVM Developers Mailing List Subject: Re: [LLVMdev] Tablegen to match a literal in an instruction Micah, I don't see anything wrong with this offhand. Have you tried getting the debug output

On Apr 18, 2007, at 11:25 AM, Christopher Lamb wrote: > I noticed that the TableGen code emitter generator assumes that the > instruction fields are declared in the instruction format in the > same order that operands are defined. This seems like a bad > dependence to me, and that TableGen should match the name of field > declared in the instruction with the name of the