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, CPU16Regs:$rz)
class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern,
InstrItinClass itin> :
FRRR16<_f, (outs CPU16Regs:$rz), (ins CPU16Regs:$rx,
CPU16Regs:$ry),
!strconcat(asmstr, "\t$rz, $rx, $ry"),
pattern, itin>;
class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>:
FRRR16<I.f, (outs CPU16Regs:$rx), (ins CPU16Regs:$ry, CPU16Regs:$rz),
// tablegen bug: should be I.OutOperandList, I.InOperandList,
I.AsmString,
[(set CPU16Regs:$rx, (OpNode CPU16Regs:$ry, CPU16Regs:$rz))],
I.Itinerary > {
let isCommutable = isComm;
let isReMaterializable = 1;
}
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 going on inside of TableGen to make `I.f` and `I.AsmString` valid... --Sean Silva On Mon, Jul 2, 2012 at 8:07 PM, reed kotler <rkotler at mips.com> wrote:> 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, CPU16Regs:$rz) > > > class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern, > InstrItinClass itin> : > FRRR16<_f, (outs CPU16Regs:$rz), (ins CPU16Regs:$rx, > CPU16Regs:$ry), > !strconcat(asmstr, "\t$rz, $rx, $ry"), > pattern, itin>; > > class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>: > FRRR16<I.f, (outs CPU16Regs:$rx), (ins CPU16Regs:$ry, CPU16Regs:$rz), > // tablegen bug: should be I.OutOperandList, I.InOperandList, > I.AsmString, > [(set CPU16Regs:$rx, (OpNode CPU16Regs:$ry, CPU16Regs:$rz))], > I.Itinerary > { > let isCommutable = isComm; > let isReMaterializable = 1; > } > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
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 > going on inside of TableGen to make `I.f` and `I.AsmString` valid... > > --Sean Silva > > On Mon, Jul 2, 2012 at 8:07 PM, reed kotler<rkotler at mips.com> wrote: >> 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, CPU16Regs:$rz) >> >> >> class FRRR16_ins<bits<2> _f, string asmstr, list<dag> pattern, >> InstrItinClass itin> : >> FRRR16<_f, (outs CPU16Regs:$rz), (ins CPU16Regs:$rx, >> CPU16Regs:$ry), >> !strconcat(asmstr, "\t$rz, $rx, $ry"), >> pattern, itin>; >> >> class ArithLogicR16<FRRR16_ins I, SDNode OpNode, bit isComm = 0>: >> FRRR16<I.f, (outs CPU16Regs:$rx), (ins CPU16Regs:$ry, CPU16Regs:$rz), >> // tablegen bug: should be I.OutOperandList, I.InOperandList, >> I.AsmString, >> [(set CPU16Regs:$rx, (OpNode CPU16Regs:$ry, CPU16Regs:$rz))], >> I.Itinerary> { >> let isCommutable = isComm; >> let isReMaterializable = 1; >> } >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev