similar to: [LLVMdev] Instruction Encodings in TableGen

On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com>wrote: > On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > > I'm starting to look into binary instruction encodings in TableGen, and > I'm > > a bit confused on how the instruction fields are populated. Perhaps I'm > > just being dense, but I cannot see how SDAG

On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > I'm starting to look into binary instruction encodings in TableGen, and I'm > a bit confused on how the instruction fields are populated. Perhaps I'm > just being dense, but I cannot see how SDAG operands are translated into > the encoding fields. Can someone please explain the following snippet from

On Tue, Jul 24, 2012 at 8:46 PM, Jim Grosbach <grosbach at apple.com> wrote: > > On Jul 24, 2012, at 3:52 PM, Justin Holewinski < > justin.holewinski at gmail.com> wrote: > > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com>wrote: > >> On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: >> > I'm

On Jul 24, 2012, at 3:52 PM, Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard <thomas.stellard at amd.com> wrote: > On Tue, Jul 24, 2012 at 03:25:14PM -0400, Justin Holewinski wrote: > > I'm starting to look into binary instruction encodings in TableGen, and I'm > > a bit confused on how the instruction

On Wed, 25 Jul 2012 07:51:28 -0400 Justin Holewinski <justin.holewinski at gmail.com> wrote: > On Tue, Jul 24, 2012 at 8:46 PM, Jim Grosbach <grosbach at apple.com> > wrote: > > > > > On Jul 24, 2012, at 3:52 PM, Justin Holewinski < > > justin.holewinski at gmail.com> wrote: > > > > On Tue, Jul 24, 2012 at 3:59 PM, Tom Stellard > >

No, I don't. Cheers, Gary Dale Johannesen wrote: > This looks OK to check in, do you have write access? > > On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > > >Dale Johannesen wrote: > >>On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > >>>I'm trying to implement llvm.memory.barrier on PowerPC. I've > >>>modelled my patch

Dale Johannesen wrote: > On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > > I'm trying to implement llvm.memory.barrier on PowerPC. I've > > modelled my patch (attached) on the implementation in X86, but > > when I try and compile my test file (also attached) with llc I > > get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier > >

On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: > Hi all, > > I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled > my patch (attached) on the implementation in X86, but when I try and > compile my test file (also attached) with llc I get the error "Cannot > yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, > 0x10fa4be0,

This looks OK to check in, do you have write access? On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: > Dale Johannesen wrote: >> On Aug 19, 2008, at 7:18 AMPDT, Gary Benson wrote: >>> I'm trying to implement llvm.memory.barrier on PowerPC. I've >>> modelled my patch (attached) on the implementation in X86, but >>> when I try and compile my test

Hi all, I'm trying to implement llvm.memory.barrier on PowerPC. I've modelled my patch (attached) on the implementation in X86, but when I try and compile my test file (also attached) with llc I get the error "Cannot yet select: 0x10fa4ad0: ch = MemBarrier 0x10fa4828, 0x10fa4c68, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0, 0x10fa4be0". This presumably means my "membarrier"

OK, I've checked it in for you, thanks. Please do contact Chris about write access. On Aug 22, 2008, at 12:38 AMPDT, Gary Benson wrote: > No, I don't. > > Cheers, > Gary > > Dale Johannesen wrote: >> This looks OK to check in, do you have write access? >> >> On Aug 21, 2008, at 6:38 AMPDT, Gary Benson wrote: >> >>> Dale Johannesen

Hi, In tablegen file inside class we have variables declared inside a class. Say in PPC there is this class BForm<bits<6> opcode, bit aa, bit lk, dag OOL, dag IOL, string asmstr> : I<opcode, OOL, IOL, asmstr, IIC_BrB> { bits<7> BIBO; // 2 bits of BI and 5 bits of BO. bits<3> CR; bits<14> BD; How does the generator match each variable against an

I'm getting this incompatible type assertion when I run tblgen on my .td files: llvm/include/llvm/Support/Casting.h:237: typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::DefInit; Y = llvm::Init; typename llvm::cast_retty<X, Y*>::ret_type = llvm::DefInit*]: Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible

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

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,

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,

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

Nothing... I'll show you all the info related to: The intrinsic: def int_soru_sre : Intrinsic<[llvm_void_ty, llvm_i32_ty], [IntrWriteMem]>; The lower instruction (in MIPS): class SORUI<bits<6> op, dag outs, dag ins, string asmstr, list<dag> pattern, InstrItinClass itin>: FI<op, outs, ins, asmstr, pattern, itin> { let isBarrier = 1; // or call,