similar to: wrong operand in getBinaryCodeForInstr

Hi, I have added Branch condition BGEID like below… *def : Pat<(brcond (setcc (i32 GR32:$L), (i32 GR32:$R), SETGE), bb:$T),* * (BGEID (CMP GR32:$L, GR32:$R), bb:$T)>;* *def BGEID : TBT<0b101110, (outs), (ins GR32:$ra, brtarget:$offset), "bgeid\t$ra,$offset", [], IIC_BRc> {* * let rd = 0b10101;* *}* *def brtarget : Operand<OtherVT>* *{*

Hi, It seems like CodeEmitterGen gets confused when we use named suboperands. sample code: def memsrc : Operand<i16> { let PrintMethod = "printSrcMemOperand"; let MIOperandInfo = (ops GR16:$ra, i16imm:$imm_i16); let ParserMatchClass = memAsmOperand; } def LOAD16m : Inst32rri<0x0, (outs GR16:$rb), (ins memsrc:$src2), "ldi16 {$rb,

+llvmdev -llvmcommits On Fri, Nov 12, 2010 at 8:03 AM, Jim Grosbach <grosbach at apple.com> wrote: > Sorta. getBinaryCodeForInst() is auto-generated by tablegen, so shouldn't be modified directly. The target can register hooks for instruction operands for any special encoding needs, including registering fixups, using the EncoderMethod string. For an example, have a look at the

I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) 1) VFP/Neon instructions don't encode correctly at al, because the encoding methods generated by tablegen for them

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

----- Original Message ----- > From: "Tom Stellard" <tom at stellard.net> > To: "Hal Finkel" <hfinkel at anl.gov> > Cc: "LLVM Developers Mailing List" <llvmdev at cs.uiuc.edu> > Sent: Thursday, March 13, 2014 9:46:22 AM > Subject: Re: [LLVMdev] Be Careful with Positionally-Encoded Operands (AArch64, Mips, AMDGPU, etc.) > > On

Hello, Some of the backends seem to be combining positional and named operands when defining some instructions such that some of the positional operands overlap with some of the named operands. I suspect this is not intentional; here's an example: AArch64 has the following instruction definition: SMULHxxx { field bits<32> Inst = { 1, 0, 0, 1, 1, 0, 1, 1, 0, 1, 0, Rm{4}, Rm{3},

Hi, we have seen proper register numbers when we have generated assembly files through clang but when we generated dump files from object file then we didn't see expected register numbers. Note : all registers are replaced with R0 *Disassembly of section .text:00000000 <main>: 0: 3000ffcc addik r0, r0, -52 4: f8000000 swi r0, r0, 0 8:

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

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

Hi all, I'm compiling current SVN HEAD on Linux/x86. The tests are failing on PowerPC due to the following assertion failure : JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: getMachineOpValue(const llvm::MachineInstr&, const llvm::MachineOperand&) const: Assertion `MovePCtoLROffset && "MovePCtoLR not seen yet?"'

Erik de Castro Lopo <mle+cl <at> mega-nerd.com> writes: > > Hi all, > > I'm compiling current SVN HEAD on Linux/x86. The tests are failing > on PowerPC due to the following assertion failure : > > JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: > getMachineOpValue(const llvm::MachineInstr&, const

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

Hi Evan, My apologies: I've been so excited on sharing the functionality that I forgot to review my patch! Evan Cheng wrote: > On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > > >> Hi everyone, >> >> Here's a patch that enables exception handling when jitting. I've >> copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may

Erik de Castro Lopo <mle+cl <at> mega-nerd.com> writes: > > Hi all, > > I'm compiling current SVN HEAD on Linux/x86. The tests are failing > on PowerPC due to the following assertion failure : > > JITTests: PPCCodeEmitter.cpp:152: unsigned int<unnamed>::PPCCodeEmitter:: > getMachineOpValue(const llvm::MachineInstr&, const

On Dec 10, 2007, at 9:52 AM, Nicolas Geoffray wrote: > Hi everyone, > > Here's a patch that enables exception handling when jitting. I've > copy/pasted _many_code from lib/Codegen/DwarfWriter.cpp, so we may > need > to factorize it, but the functionality is there and I'm very happy > with > it :) Very nice! I don't know enough about EH, someone else

I'm not working on it, but I might be able to help find the problem. What this means is that you're generating code in PIC mode, and an object that requires a PIC register to reference is being addressed, and no PIC register was allocated. The allocation was supposed to happen in PPCDAGtoDAGISel::Select when the reference was processed, and a MovePCtoLR instruction inserted at that

Craig, On Aug 30, 2011, at 12:51 PM, Craig Smith wrote: > I recently tried to update from LLVM 2.8 and 2.9 and ran into several bad issues with JIT support on ARM. > I ran into several distinct issues so far, and there are probably others. (None of these problems appear to be fixed in the current svn head either as far as I can tell.) The non-MC-based ARM JIT path is known not to work,