search for: x86mccodeemitter

...and it even solves most of the hard part of feature request for .code16 in bug 8684 — which was actually why I started prodding at this. But I could do with some help with the 16-bit signed relocation handling, which I've split into a subsequent patch. diff --git a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp index 7952607..12a30cf 100644 --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst &MI, unsigned Op, uns...

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: > Put the TA's back. EVEX/EVEX_4V does not replace TA. They are for > different things. An...

...he hard > part of feature request for .code16 in bug 8684 — which was actually why > I started prodding at this. But I could do with some help with the > 16-bit signed relocation handling, which I've split into a subsequent > patch. > > diff --git a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > index 7952607..12a30cf 100644 > --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst >...

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. > > What do you intend to do with the binary output once you have it?...

...: 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 this condition; if(HasTA) ++SrcRegNum; now getting no error. please tell me whether my method is correct? Also please confirm this whether i need to make changes in MC framework to emit binary code of my vector instructions. So far i made no changes or additions in MC framew...

hi, i am struggling to understand how MRMDestReg is used in X86. in X86InstrFormat.td, we have this: class Format<bits<7> val> { bits<7> Value = val; } def MRMDestReg : Format<3> i think eventually, MRMDestReg is mapped back to ModMRM byte. but this still doesnt make sense to me why MRMDestReg is defined this way, and how it is mapped back to ModRM byte. any hint

...; 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 this condition; >> >> if(HasTA) >> ++SrcRegNum; >> >> now getting no error. >> >> please tell me whether my method is correct? Also please confirm this >> whether i need to make changes in MC framework to emit bin...

...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 this condition; >>>>>> >>>>>> if(HasTA) >>>>>> ++SrcRegNum; >>>>>> >>>>>> now getting no error. >>>>>> >>>>&g...

...b_1<def> = P_256B_VADD %R_0_REG2048b_1<kill>, %R_0_REG2048b_0<kill> I am getting the following error: Unknown immediate size UNREACHABLE executed at /lib/Target/X86/MCTargetDesc/X86BaseInfo.h:574! i made extensive use of gdb and after debugging i found the line with issue in X86MCCodeEmitter.cpp. Here NumOps=3 (all registers). and CurOp is 1st initialized to 0. then, the following code gets executed; case X86II::MRMDestReg: { EmitByte(BaseOpcode, CurByte, OS); unsigned SrcRegNum = CurOp + 1; //SrcRegNum=1 EmitRegModRMByte(MI.getOperand(CurOp), GetX86RegN...

...adc3eca abort (/lib/x86_64-linux-gnu/libc.so.6+0x36eca) #7 0x000000000195f6c0 LLVMInstallFatalErrorHandler lib/Support/ErrorHandling.cpp:133:0 #8 0x0000000000c08966 llvm::X86II::getSizeOfImm(unsigned long) lib/Target/X86/MCTargetDesc/X86BaseInfo.h:577:29 #9 0x0000000000c04c2a (anonymous namespace)::X86MCCodeEmitter::encodeInstruction(llvm::MCInst const&, llvm::raw_ostream&, llvm::SmallVectorImpl<llvm::MCFixup>&, llvm::MCSubtargetInfo const&) const lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp:1512:67 #10 0x00000000015884b3 llvm::MCELFStreamer::EmitInstToData(llvm::MCInst const&, l...

..._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 this condition; >>>> >>>> if(HasTA) >>>> ++SrcRegNum; >>>> >>>> now getting no error. >>>> >>>> please tell me whether my method is correct? Also please confirm...

Hi, I am trying to undertand which code in LLVM patches the fixups generated by assembler. Here is what I am doing: I use "llvm-mc" to compile X86 assembly code, like below: $ echo "jmp 5000" | ./bin/llvm-mc -assemble -triple=i386 -show-encoding -x86-asm-syntax=att -output-asm-variant=1 .text jmp 5000 # encoding: [0xeb,A]

...sh to make sure that there's enough isa support for your target in the mips backend as well. There are definitely plenty of things in that target to work on while the rest of the JIT is coming up around. A good start point, as Eric said, would be to add the MC support for the mips backend, see X86MCCodeEmitter.cpp and X86MCInstLower.cpp for a more concrete example of how it can be done. -- Bruno Cardoso Lopes http://www.brunocardoso.cc

I don't think changing to VEX_4VOp3 to VEX_4V is the right fix. I think the fix is to increment CurOp twice at the start for these instructions so that only the input operands are used for encoding. Also, I just submitted a patch to revert the operand order for these instructions in the assembler/disassembler. Destination register should appear on the right and the mask should appear on the

Yes, there is an easy way to fix this. MRMSrcMem assumes register, memory, vvvv register if VEX_4VOp3 is true and assumes register, vvvv register, memory if VEX_4V is true. I just need to change the flag from VEX_4VOp3 to VEX_4V. There are a few places where we assume only the 2nd operand can be tied-to: Desc->getOperandConstraint(1, MCOI::TIED_TO) != -1 (hard-coded index 1) I will fix those

Hello, I need the expression in string. How can i convert llvm::MCExpr * to string? Please help. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171005/50817330/attachment.html>

Hi, By way of example, I have the following instruction: 44 8b 80 c8 03 00 00 movl 968(%rax), %r8d 1) How is this represented in MCInst? 2) Is there information in MCInst that would tell me which bytes of the instruction are responsible for the 968? The reason I am asking is that I want to work with the bytes disassembled/decoded to an instruction at MCInst level.

...n Koi via llvm-dev wrote: > >> >> I am trying to undertand which code in LLVM patches the fixups generated >> by assembler. >> >> > What do you mean exactly? The actual machine code is generated by > MCCodeEmitter, for example > lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > > The relocations from the object files are applied by the linker, not LLVM. > Do you mean the LLVM linker will do the relocation? Do you have any hints on where to look at linker source of LLVM to see how this is done? Thanks. > > -Krzysztof > > > -- > Qualc...

On Nov 17, 2010, at 12:37 AM, Michael.Kang wrote: > On Wed, Nov 17, 2010 at 4:30 PM, James Molloy <James.Molloy at arm.com> wrote: >> Hi, >> >> There are numerous emails flying around the list at the moment regarding the state of the JIT. In its current state it is infeasible to add support for another architecture (very difficult to say the least) - there are plans

Hi Eli, Thanks, I’ll look into that then! Cheers, Taddeüs From: Friedman, Eli Sent: Wednesday, 2 August 2017 19:48 To: Taddeus; llvm-dev at lists.llvm.org Subject: Re: [llvm-dev] Efficiently ignoring upper 32 pointer bits whendereferencing On 8/2/2017 9:03 AM, Taddeus via llvm-dev wrote: > Hi all, > > I am experiencing a problem with the representation of addresses in > the x86_64