similar to: [LLVMdev] Auxiliary operand types for disassembler.

Hi Sid, This feels like it’s exposing too much of the disassembler internals into the MCOperand representation. I’m not sure I follow why that’s necessary. Can you elaborate a bit? -Jim On Jun 25, 2013, at 8:24 AM, Sid Manning <sidneym at codeaurora.org> wrote: > > I'm working on a disassembler for hexagon (vliw) architecture and I would like to add an additional operand type,

On 06/25/2013 04:46 PM, Jim Grosbach wrote: > Hi Sid, > > This feels like it’s exposing too much of the disassembler internals > into the MCOperand representation. I’m not sure I follow why that’s > necessary. Can you elaborate a bit? > A packet contains 1-4 insns and until the contents of the entire packet are known the meaning of any individual insn is not known with 100%

The `isBranch` flag is already set on the branch instructions. Furthermore, we do use the `isBranch()` query in a few places in the PPC back end, so this does work. Perhaps there's something specific about the lldb usage? Is it somehow possible that the `isBranch()` query is called on the wrong instruction? Would you be able to provide a test case that reproduces the issue? On Thu, Nov 30,

> But where is the flat set? Maybe I can debug and check what is going on. The MCInstrDesc are in a table in lib/Target/PowerPC/PPCGenInstrInfo.inc of your build directory. > Some additional information: > > MCInst opcode: 0x7cb > Decode Index: 0x1e I had assumed this would have dissembled to '// Inst #234 = BC' which does have the branch flag set, but I think that

Hi, In GCC there is one useful option -dp (or -dP for more verbose output) to annotate assembler with instruction patterns, that was used when assembler was generated. For example: double test(long long s) { return s; } gcc -S -dp -O0 test.c test: .LFB0: .cfi_startproc pushq %rbp # 18 *pushdi2_rex64/1 [length = 1] .cfi_def_cfa_offset 16 movq %rsp, %rbp # 19 *movdi_1_rex64/2

On 02.03.2012, at 09:20, Konstantin Vladimirov wrote: > Hi, > > In GCC there is one useful option -dp (or -dP for more verbose output) > to annotate assembler with instruction patterns, that was used when > assembler was generated. For example: The internal "-mllvm -show-mc-inst" option is probably as close as you can get. $ clang -S -O0 test.c -mllvm -show-mc-inst -o

Hi everyone. We're interested in contributing a Hexagon assembler to MC and we're looking for comments on a good way to integrate the grammar in to the infrastructure. We rely on having a robust assembler because we have a large base of developers that write in assembly due to low power requirements for mobile devices. We put in some C-like concepts to make the syntax easier and this

Hi there! In the x86 disassembler I noticed an if-statement with a duplicated branch. Are these intended to be identical? Best regards, Nicolas Kaiser -- diff -ur llvm-2.8.orig/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c llvm-2.8/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c --- llvm-2.8.orig/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c 2010-05-06 22:59:00.000000000 +0200

On Jun 22, 2011, at 9:00 AM, Renato Golin wrote: > On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote: >>> This sounds like a dead end as newer binutils are GPLv3. >> >> Yeah, that's definitely a very real concern and a big motivation to get the MC based asm parser whipped into usable shape. We're much more in control of our own destiny then.

hi, i think the current X86 disassembler is quite broken and fails badly on handling REX for x86_64 code. below are some examples: $ echo "0x0f,0xeb,0xc3"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text por %mm3, %mm0 $ echo "0x40,0x0f,0xeb,0xc3"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 .text por %mm3, %mm0 $ echo

Hello everyone, I'm a newbie of llvm. I'm trying to insert Intel MPX instruction BNDCU with BuildMI. I add my machinefunctionpass at addPreEmitPass2. Here is the code of insertion: BuildMI(MBB, MI, DL, TII->get(X86::BNDCU64rr)).addReg(X86::BND2, RegState::Define).addReg(X86::R10); And here is to stack track when I compiler program with modified llc:

On Jun 22, 2011, at 6:15 PM, Jim Grosbach wrote: > > On Jun 22, 2011, at 9:00 AM, Renato Golin wrote: > >> On 22 June 2011 16:50, Jim Grosbach <grosbach at apple.com> wrote: >>>> This sounds like a dead end as newer binutils are GPLv3. >>> >>> Yeah, that's definitely a very real concern and a big motivation to get the MC based asm parser

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;

Dear mailing list: the attached diff implements a table-driven disassembler for the X86 architecture (16-, 32-, and 64-bit incarnations), integrated into the MC framework. The disassembler is table-driven, using a custom TableGen backend to generate hierarchical tables optimized for fast decode. The disassembler consumes MemoryObjects and produces arrays of MCInsts, adhering to the

> I will do a run with --merge-strings. This should probably the the > default to match other ELF linkers. Trying --merge-strings with today's trunk I got * comment got 77 797 bytes smaller. * rodata got 9 394 257 bytes smaller. Comparing with gold, comment now has the same size and rodata is 55 021 bytes bigger. Amusingly, merging strings seems to make lld a bit faster. With

there is an if-else code in X86DisassemblerDecoder.c that does exactly the same thing on both paths. so this patch removes the redundant path. thanks, Jun diff --git a/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c b/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c index 20e61da..3932ea1 100644 --- a/lib/Target/X86/Disassembler/X86DisassemblerDecoder.c +++

There is a problem on X86 disassembler for instructions beginning with x86 prefix : $ echo "0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble movdqa (%edi), %xmm1 $ echo "0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble pushl %ebx <stdin>:1:6: warning: invalid instruction encoding 0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00

MAD IMM has a very specific SDST == SSRC2 requirement, so don't emit Signed-off-by: Roy Spliet <rspliet at eclipso.eu> --- .../drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp | 18 ++++++++++++------ .../drivers/nouveau/codegen/nv50_ir_target_nv50.cpp | 2 +- 2 files changed, 13 insertions(+), 7 deletions(-) diff --git a/src/gallium/drivers/nouveau/codegen/nv50_ir_emit_nv50.cpp

Hi, Intel's Xed can interpret "43 40 04 75" as "add al, 0x75", but LLVM's X86 disassembler considers this invalid code. I guess the reason is that LLVM fails to recognize the REX prefix in this case. Is this correct? Thanks. Jun -------------- next part -------------- An HTML attachment was scrubbed... URL:

I looked at this briefly, I think it causes some mistakes that get reversed later in fixupReg. The disassembler design is a bit of a mess with regards to prefixes and operand size. On Tue, Apr 1, 2014 at 4:43 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > > > > On Mon, Mar 31, 2014 at 11:48 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > >> Hi, >> >>