similar to: [LLVMdev] Getting x86-64 assembly listing

I was away doing other things for a while, but I have an API patch separated out, which (in addition to being much smaller than past megapatches) corrects two issues Chris identified in his most recent set of patches: - First, it makes the API a good deal simpler. Now, you can instantiate a single MCDisassembler and, each time you want an instruction disassembled, you can simply pass

On Aug 19, 2009, at 4:39 PM, Sean Callanan wrote: > thanks for your comments. I'll respond to them individually. I've > attached a new revision of the patch that addresses them. Patch > built and tested against SVN 79487, with the additional attached fix > that fixes an Intel table bug. Thanks Sean, comments below. Are you sure you attached the updated patch? I

Hi Evan, all, The most obvious thing to me would be to extend the load instruction to have an additional form that takes a vector of pointers instead of a single pointer. This form would return a vector of values instead of a single value. If a gather instruction is not available on the target, then the load could be lowered to a series of scalar loads and insertelements. Thanks, Nick On

Hi, I'm using LLVM for JIT compilation of shaders for my ray tracer (http://www.indigorenderer.com). My primary development target is 32 bit and 64 bit Windows. JIT compilation of shaders is working great for x86 code, but for x64 code LLVM doesn't really work, due to ABI incompatibilties in the form of calling convention errors with x64 windows, I think. Anyway, my questions are as

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" > >

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 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

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] $

Hi All, I was in the process of implementing a gathering load for my language. I got the getelementptr vector form working. However there doesn't seem to be a way to load a vector of values using the vector of pointers from getelementptr. Am I correct that this is not possible with LLVM IR currently (apart from with the avx2 gather intrinsic)? And if so, are there plans to allow

Copy Ii32 in X86InstrFormats.td rename to Ii64 and change Imm32 to Imm64. Instantiate your instruction inheriting from Ii64. Pass RawFrm to the form parameter. Initial documentation for the encoding system is attached. ~Craig On Wed, Mar 28, 2018 at 4:50 PM, Gus Smith via llvm-dev < llvm-dev at lists.llvm.org> wrote: > I am attempting to create an instruction which takes a single

On Aug 24, 2009, at 3:05 PM, Ivo wrote: > On Monday 24 August 2009 23:27, Albert Graef wrote: >> Thank you also for the hint about bitcode reading/writing. I'm >> aware of >> this, but I actually prefer the .ll output because it's human- >> readable, >> which is great for debugging purposes. I might add a bitcode writer >> some >> time,

Hi, The x86 (32-bit) disassembler can't disassemble any of the following: 0x2b 0xc9 0x8a 0xc8 0xdd 0x04 0x24 These are: subl %ecx, %ecx movb %al, %cl fldl (%esp) I've attached patches to bug#8873 which fix all these issues, but I'm not confident that I've fixed them the right way. The first two problems are caused by the instructions setting 'isCodeGenOnly =

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 Sean, > 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

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'am now considering converting x86 machine assembly into LLVM IR, does anyone know about any existing project or resource related to this area? Any difficulities or any ideas on this? thanks for your replies in advance. cradnil 2008-03-04 -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 08/03/2015 18:07, Daniel Berlin wrote: > > > On Sun, Mar 8, 2015 at 9:55 AM, Nicholas Chapman > <admin at indigorenderer.com <mailto:admin at indigorenderer.com>> wrote: > > Hi all, > I have identified what seems to be a limitation of LLVM with > regard to marking 'sret functions' as pure/readonly. > > For some context - I have

Hi All, I have run into an issue when writing some LLVM code to read from a C++ structure. The structure as defined in LLVM is { { <4 x float> }, { <4 x float> }, { <16 x float> }, { <4 x float> }, { <4 x float> } }. On Windows, with Visual Studio 2012, the vector members of the structure are packed tightly together. However, LLVM seems to be leaving 32 bytes

Right, I'm suggesting we keep llvm_shutdown() for users who want this control, but also destroy still-live ManagedStatic instances if llvm_shutdown() is not called. This helps in the case where there is not a clear time when llvm_shutdown() can be called, especially given that LLVM cannot be resurrected in the same process due to current limitations in the pass registry, and perhaps

Hello, I have seen this bug for quite a while, and even in the latest code it is still there: that is X86 disassembler does not handle 0x66 prefix properly, if it is put behind 0xF3 prefix. The below commands should return the same output, but not. $ echo "0xf3 0x66 0xa5"|./build/bin/llvm-mc --disassemble -triple=x86_64 -output-asm-variant=1 .text rep movsw word ptr es:[rdi], word ptr