search for: getmachineopvalu

...ode, 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 operand? For the corresponding PPCGenMCCodeEmitter.inc for this the entry is // op: BIBO op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); // op: CR op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI); // op: BD op = getCondBrEncoding(MI, 2, Fixups, STI); How does the generator know that BIBO is op0 and CR is op1 and so on? Is it based on the order of the declaration...

...> is, by default, no overlap checking, it also gets mapped to the > > first operand: GPR64:$Rd. The result, from > > AArch64GenMCCodeEmitter.inc is: > > > > case AArch64::SMULHxxx: > > case AArch64::UMULHxxx: { > > // op: Rd > > op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); > > Value |= op & UINT64_C(31); > > // op: Rn > > op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI); > > Value |= (op & UINT64_C(31)) << 5; > > // op: Rm > > op = getMa...

...t about Ra? Ra contributes to defining the bits in Inst, and because there is, by default, no overlap checking, it also gets mapped to the first operand: GPR64:$Rd. The result, from AArch64GenMCCodeEmitter.inc is: case AArch64::SMULHxxx: case AArch64::UMULHxxx: { // op: Rd op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); Value |= op & UINT64_C(31); // op: Rn op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI); Value |= (op & UINT64_C(31)) << 5; // op: Rm op = getMachineOpValue(MI, MI.getOperand(2), Fixups, STI); Value...

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?"' failed. Is anyone working on the PowerPC backend? Erik -- ---------------------------------------------------------------------- Erik de Ca...

...encoded (and the physical registers are known), where do > > these values come from? A grep for RST doesn't come up with anything > > useful. Is there C++ code somewhere that scans the operands of all > > instructions and performs the actual encoding? > > > > The getMachineOpValue() function does the encoding for the non-MC code > emitter. The MC code emitter might be different though. > Yeah, I see the calls to getMachineOpValue() in the generated code, but it seems like it just processes the fields of the TableGen class in the order that they appear, e.g. A, RST,...

...l registers are known), where do >> > these values come from? A grep for RST doesn't come up with anything >> > useful. Is there C++ code somewhere that scans the operands of all >> > instructions and performs the actual encoding? >> > >> >> The getMachineOpValue() function does the encoding for the non-MC code >> emitter. The MC code emitter might be different though. >> > > Yeah, I see the calls to getMachineOpValue() in the generated code, but it > seems like it just processes the fields of the TableGen class in the order > that...

...: TargetInst32<opcode, outs, ins, asmstr, pattern> { bits<5> rb; bits<5> ra; bits<16> imm_i16; let Inst{9-5} = rb; // operand 0 let Inst{4-0} = ra; // operand 1 let Inst{31-16} = imm_i16; // operand 2 } And this code was generated // op: rb -- Operand #0 op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); Value |= (op & UINT64_C(31)) << 5; // op: ra -- Operand #0 op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); Value |= op & UINT64_C(31); // op: imm_i16 -- Operand #1 op = getMachineOpValue(MI, MI.getOperand(1), Fixups, STI); Value |= (op...

...ncoded (and the physical registers are known), where do > > these values come from? A grep for RST doesn't come up with anything > > useful. Is there C++ code somewhere that scans the operands of all > > instructions and performs the actual encoding? > > > > The getMachineOpValue() function does the encoding for the non-MC code > emitter. The MC code emitter might be different though. > > Yeah, I see the calls to getMachineOpValue() in the generated code, but it seems like it just processes the fields of the TableGen class in the order that they appear, e.g. A,...

...do these values come from? A grep for RST doesn't come up > >> > with anything useful. Is there C++ code somewhere that scans > >> > the operands of all instructions and performs the actual > >> > encoding? > >> > > >> > >> The getMachineOpValue() function does the encoding for the non-MC > >> code emitter. The MC code emitter might be different though. > >> > > > > Yeah, I see the calls to getMachineOpValue() in the generated code, > > but it seems like it just processes the fields of the TableGen &gt...

...hen the > instruction is encoded (and the physical registers are known), where do > these values come from? A grep for RST doesn't come up with anything > useful. Is there C++ code somewhere that scans the operands of all > instructions and performs the actual encoding? > The getMachineOpValue() function does the encoding for the non-MC code emitter. The MC code emitter might be different though. -Tom > -- > > Thanks, > > Justin Holewinski > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http...

...t encode correctly at al, because the encoding methods generated by tablegen for them clobber the constructed binary value when they try to implement 'PostEncoderMethod' support , for example, from ARMGenCodeEmitter.inc: case ARM::VLDRD: case ARM::VSTRD: { // op: p op = getMachineOpValue(MI, MI.getOperand(3)); Value |= (op & 15U) << 28; // etc ... Value = VFPThumb2PostEncoder(MI, Value); // <--- overwrites Value! break; } The bug here is that in utils/TableGen/CodeEmitterGen.cpp, line 196: Case += " Value = " + PostE...

...dName() to print the magic :lower16: and :upper16: asm tags for .s emission Currently, movt/movw emission works correctly in .s, but not in .o emission This lead me to believe that the correct place to put the code to handle MCSymbolRefExpr::VK_ARM_(HI||LO)16 for the .o path was to place a case in getMachineOpValue() (i.e. not ARMMCCodeEmitter::getBinaryCodeForInstr like I mistakenly wrote in my prior email.) Are you implying that the movt/movw instruction definition in the .td files need to be fixed up instead to declare a new special case for .o emission via the EncoderMethod string, for the .o emission o...

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 the PPC back-end. The AND instruction in PPC is defined as: 1011 def AND :

...<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 llvm::MachineOperand&) > const: Assertion `MovePCtoLROffset && "MovePCtoLR not seen yet?"' failed. > > Is anyone working on the PowerPC backend? > > Erik I'm seeing these same errors on powerpc-yellowdog-linux...

Hi, *case MICROBLAZE::BGEID:* * {* * // op: raencoder* * op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI);* * Value |= (op & UINT64_C(31)) << 16;* * // op: imm16* * op = getMachineOpValue(MI, MI.getOperand(0), Fixups, STI); -> should be operand[1]* * Value |= op & UINT64_C(65535);* * break;* * }* I have added dif...

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:

...<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 llvm::MachineOperand&) > const: Assertion `MovePCtoLROffset && "MovePCtoLR not seen yet?"' failed. > > Is anyone working on the PowerPC backend? > > Erik I added build, host, target = ppc-unknown-linux-gnu and en...

Thank you :) If you mean this field, it looks everything is ok: field bits<16> Inst = { 0, 1, 1, 0, 1, 0, 0, 0, 0, 0, Dr{2}, Dr{1}, Dr{0}, At{0}, 0, 0 }; Is possible that the problem might be on the TestAsmParser.cpp side? On Thu, Sep 17, 2015 at 4:18 PM, Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On 9/17/2015 9:04 AM, Krzysztof Parzyszek via llvm-dev

...re the problem is. Here is the backtrace, (gdb) bt #0 0x00000fffb7b84090 in .raise () from /lib/libc.so.6 #1 0x00000fffb7b85ca4 in .abort () from /lib/libc.so.6 #2 0x0000000010517b9c in ._ZN4llvm25llvm_unreachable_internalEPKcS1_j () #3 0x0000000010047aa0 in ._ZN12_GLOBAL__N_114PPCCodeEmitter17getMachineOpValueERKN4llvm12MachineInstrERKNS1_14MachineOperandE () #4 0x0000000010048ff4 in ._ZN12_GLOBAL__N_114PPCCodeEmitter14emitBasicBlockERN4llvm17MachineBasicBlockE () #5 0x000000001004940c in ._ZN12_GLOBAL__N_114PPCCodeEmitter20runOnMachineFunctionERN4llvm15MachineFunctionE () #6 0x00000000101f26f4 in ._...

...: > >> >> 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?"' failed. >> >> Is anyone working on the PowerPC backend? >> >> Erik > > I'm seeing these same erro...