similar to: [LLVMdev] [RFC PATCH 1/2] x86: Fix ModR/M byte output in 16-bit addressing mode

Hi David, I'm catching up on email at the moment so I don't know if you've done this, but patches should go to llvm-commits for review if you wouldn't mind. Thanks! -eric On Thu Dec 12 2013 at 8:39:19 AM, David Woodhouse <dwmw2 at infradead.org> wrote: > This attempts to address http://llvm.org/bugs/show_bug.cgi?id=18220 > It also fixes a test which was requiring

Hello, I am trying to emit binary for my implemented vector instructions. Although yet i havent done any change or addition in MC framework, For vector load instruction there are no error coming. But for vector add instruction is something like this; > %R_0_REG2048b_1<def> = P_256B_VADD %R_0_REG2048b_1<kill>, %R_0_REG2048b_0<kill> I am getting the following error: Unknown

Thank You. My add instruction has TA as follows: def P_256B_VADD : I<0xE1, MRMDestReg, (outs VRP_2048:$dst), (ins VRP_2048:$src1, VRPIM_2048:$src2),"P_256B_VADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRP_2048:$dst, (add (v64i32 VRP_2048:$src1), (v64i32 VRP_2048:$src2)))]>, TA; so i defined; bool HasTA = TSFlags & X86II::TA; in x86MCCodeEmitter.cpp then used

You are right. But when i defined my instruction as follows: def P_256B_VADD : I<0xE1, MRMDestReg, (outs VRP_2048:$dst), (ins VRP_2048:$src1, VRPIM_2048:$src2),"P_256B_VADD\t{$src1, $src2, $dst|$dst, $src1, $src2}", [(set VRP_2048:$dst, (add (v64i32 VRP_2048:$src1), (v64i32 VRP_2048:$src2)))]>, VEX_4V; I get opcode conflicts? Then what to do? On Tue, Sep 5, 2017 at 3:51 AM,

Sorry to ask but what does it mean to put both? On Tue, Sep 5, 2017 at 4:01 AM, Craig Topper <craig.topper at gmail.com> wrote: > Leave TA. Put both. > > ~Craig > > On Mon, Sep 4, 2017 at 4:00 PM, hameeza ahmed <hahmed2305 at gmail.com> > wrote: > >> You are right. But when i defined my instruction as follows: >> def P_256B_VADD : I<0xE1,

Thank You. I used EVEX_4V with all the instructions. I replaced TA and EVEX both with EVEX_4V. Now, I am getting following error: llvm-tblgen: /utils/TableGen/X86RecognizableInstr.cpp:687: void llvm::X86Disassembler::RecognizableInstr::emitInstructionSpecifier(): Assertion `numPhysicalOperands >= 2 + additionalOperands && numPhysicalOperands <= 4 + additionalOperands &&

Thank You, I changed TA to EVEX or EVEX_4V. But now i am getting following error: Invalid prefix! UNREACHABLE executed at /lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:647! On Tue, Sep 5, 2017 at 4:36 AM, Craig Topper <craig.topper at gmail.com> wrote: > Not all instructions can use EVEX_4V. Move instructions in particular > cannot because they don't have 2 sources. >

I was getting same error when i keep both EVEX/EVEX_4V and TA. So, i restored my original instructions and for that i have to include bool HasTA = TSFlags & X86II::TA; in x86MCCodeEmitter.cpp then used this condition; if(HasTA) ++SrcRegNum; in order to emit binary correctly. Is it right? On Tue, Sep 5, 2017 at 5:45 AM, Craig Topper <craig.topper at gmail.com> wrote: >

Hi, Sorry for the newbie question. I downloaded llvm 1.8a and llvm-gcc3.4, tried out the simple "Hello, World" program but got the following error. My system is RedHat 9 $ ./hello lli: /home//llvm/lib/Target/X86/X86CodeEmitter.cpp:208: unsigned char ModRMByte(unsigned int, unsigned int, unsigned int): Assertion `Mod < 4 && RegOpcode < 8 && RM < 8 &&

Hi, Sorry for the newbie question. I downloaded llvm and tried out the simple "Hello, World" program but got the following error. What am I missing? I am running RHAS 3 Update 4 with GCC 3.2.3. Thanks, Bharadwaj $ ./hello lli: /home/proj/skokomish/syadaval/ia32/Sandbox/llvm/lib/Target/X86/X86CodeEmitter.cpp:208: unsigned char ModRMByte(unsigned int, unsigned int, unsigned int):

On Jun 19, 2011, at 3:20 PM, Nathan Jeffords wrote: > As it happens, I have created a patch that enables DWARF debugging on windows. It is against trunk revision 133401. I have tested using clang to compile, and mingw to link & debug. +#include "../Target/X86/X86FixupKinds.h" This indicates layering violation to me. It looks good otherwise. Do you have a testcase ? LGTM.

Gang, I'm tasked with direct object generation for Mips and am trying to not hack the code. I how exactly does one set an expression to be PC relative and if the compiler can resolve it, not produce a relocation? In our case, the backend produces an expression for the branch which is the target label. I make a call from the .td for the branch instruction which calls a routine in

I have been working on getting ELF object file writing working for the MBlaze backend. Currently, each supported backend calls ELFObjectWriter::createELFObjectWriter from within the backend's TargetAsmBackend::createObjectWriter method. The createELFObjectWriter method then creates a new backend specific ELFObjectWriter class (either X86ELFObjectWriter or ARMELFObjectWriter) by decoding a

Attached is a working patch set for llvm to be able to emit arm64 (currently as triple aarch64-apple-ios) mach-o object files, in case someone is interested. I'm not sure if the llvm maintainers want the patch given the previous message that there's going to be an official patch set from apple to support this, but here is mine. What works (tested on an iPhone 5S): * objc strings,