similar to: X86 assembler cannot jump NEAR?

I think this is really because the assembler doesn't run layout and relaxation when not dumping to an object file. I disassembled an object file with this same test case and got e9 00 00 00 00. On Fri, Feb 26, 2016 at 9:00 PM, Jun Koi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi, > > Currently X86 assembler seems to always compile "jmp _label" as a SHORT

Hi, Currently X86 assembler seems to always compile "jmp _label" as a SHORT jump with "EB" opcode: $ echo "jmp _label"|llvm-mc -assemble -triple=i386 -show-encoding .text jmp _label # encoding: [0xeb,A] My question is: can X86 assembler supports NEAR jump with opcode "E9"? I try with "near" keyword, but it is not

> On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev <llvm-dev at lists.llvm.org> wrote: > The problem is that llvm-mc always compiles "jmp" this as short jump, no matter where the target is. Hence my question. I dont know if there is any way to change this behavior. Looks like a bug to me so far. It isn't. It's just created some assembly which, when assembled, may

On Feb 28, 2016 12:08 AM, "Stephen Checkoway" <s at pahtak.org> wrote: > > > > > On Feb 27, 2016, at 4:36 AM, Jun Koi via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > The problem is that llvm-mc always compiles "jmp" this as short jump, no matter where the target is. Hence my question. I dont know if there is any way to change this

On Thu, Jun 26, 2014 at 10:23 AM, Adam Nemet <anemet at apple.com> wrote: > > > On Jun 25, 2014, at 7:05 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > > On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > >> Hi Jun, >> >> On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: >>

On Thu, Jun 26, 2014 at 5:47 AM, Adam Nemet <anemet at apple.com> wrote: > Hi Jun, > > On Jun 25, 2014, at 8:14 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > Hi, > > > > I am trying to assemble below instruction with latest LLVM code, but > fail. Am I doing something wrong, or is this a bug? > > > > > > $ echo "vaddps zmm7

On Mon, May 23, 2016 at 2:44 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Hi, > > I found a mismatch between assembler & disassembler of X86: I assembled an > instruction, then disassembled the output, but the result is not the same > as the first original code: "add qword ptr [205163983024656], 1" vs " add > qword ptr [1985229328], 1" > >

The IMM3/IMM5 come from here X86RecognizableInstr.cpp 943 TYPE("SSECC", TYPE_IMM3) 944: TYPE("AVXCC", TYPE_IMM5) On Thu, Dec 25, 2014 at 8:22 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > On Fri, Dec 26, 2014 at 11:54 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> hi, >> >> some instructions

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]

You can't use mov. I am not an x86 expert, but after quick googling: Recall that immediates are normally restricted to 32 bits. To load a larger constant into a quad register, use movabsq, which takes a full 64-bit immediate as its source [https://www.lri.fr/~filliatr/ens/compil/x86-64.pdf] Even in your example, assembler replaces mov by movq, which, say, hints:

On Wed, Dec 24, 2014 at 2:43 PM, Craig Topper <craig.topper at gmail.com> wrote: > I believe this particular error is caused by this. That seems easy enough > to just drop the bit. Do you have other non-mmx examples? > > case TYPE_MM: \ > if (index > 7) \ > *valid = 0;

Hi, I found a mismatch between assembler & disassembler of X86: I assembled an instruction, then disassembled the output, but the result is not the same as the first original code: "add qword ptr [205163983024656], 1" vs " add qword ptr [1985229328], 1" Anybody knows what is wrong? Thanks. $ echo "ADD QWORD PTR [0xba9876543210], 0x1"|llvm-mc -assemble

Hi, I am trying to assemble below instruction with latest LLVM code, but fail. Am I doing something wrong, or is this a bug? $ echo "vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}"|./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 -mcpu=knl -show-encoding -x86-asm-syntax=intel .text <stdin>:1:31: error: unknown token in expression vaddps zmm7 {k6}, zmm2, zmm4, {rd-sae}

Hi Jun, On 18/10/12 11:19, Jun Koi wrote: > On Tue, Oct 9, 2012 at 9:25 PM, Jun Koi <junkoi2004 at gmail.com> wrote: >> On Fri, Oct 5, 2012 at 3:45 PM, Jun Koi <junkoi2004 at gmail.com> wrote: >>> On Fri, Oct 5, 2012 at 3:39 PM, David Chisnall >>> <David.Chisnall at cl.cam.ac.uk> wrote: >>>> On 5 Oct 2012, at 08:34, Jun Koi wrote:

Hi James, Not sure if you've already found the problem but I've been looking at this issue a bit as a way to learn. What I've seen is that the wrong operand names are used for the instruction which causes the decoder emitter to fail to recognize the operands. The attached patch changes the names of the operands and adds a test for the disassembly of the instruction. I haven't

hi, some instructions mismatch between assembler & disassembler, like below. it seems this happens with all SSECC related instructions? thanks, Jun $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding .text cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] $

I'll look into it, thanks for the report. On Thu, Jul 30, 2015 at 11:01 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > Any ideas on this bug? > > Thanks. > > > On Wed, Jul 29, 2015 at 12:17 AM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hello, >> >> There is an issue in the latest Sparc code: while we can encode POPC, >> decode

On Tue, Oct 9, 2012 at 9:25 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > On Fri, Oct 5, 2012 at 3:45 PM, Jun Koi <junkoi2004 at gmail.com> wrote: >> On Fri, Oct 5, 2012 at 3:39 PM, David Chisnall >> <David.Chisnall at cl.cam.ac.uk> wrote: >>> On 5 Oct 2012, at 08:34, Jun Koi wrote: >>> >>>> any idea on how to fix the problem?

Well, you’ll probably need to specify which CPU for the instructions to be recognized as valid encodings. -mcpu=knl doesn’t seem sufficient, though, so there’s probably something more going on. Elena, do you know what’s happening here? It’s important that the disassembler work with the new instructions as well as the assembler. I looked but didn’t see any disassembler tests for avx512. -Jim On

Hi I want to replace all the return instructions in the program with pop <reg>; jmp <reg>. Should I use IRBuilder in LLVM IR level? I found that there is a IRBuilder::CreateIndirectBr Or Should I modify the code in lib/Target/X86/X86ISelLowering.cpp in backend ? I found that there is a X86TargetLowering::LowerCall Which is better? Thanks -------------- next part --------------