similar to: Bug in X86 assembler?

Hi, Is there any documentation on the syntax accepted by X86 assembler? I have this code in my .asm file to define data: text db "127.1.1.1 google.lk" But X86 assembler fails to understand it, with error: error: unexpected token in argument list text db "127.1.1.1 google.lk" ^ Any ideas how to fix this problem? I tried to find some

Finally I kind of modified llvm to generate assembly that can run on AMDGPU pro drivers. One problem is the performance of the code generated by llvm is about 10% slower than amdgpu's online compiler. Anything I can tune the performance up the performance of llvm?\ Thanks! On Tue, Sep 4, 2018 at 9:23 AM 董昌道 <dongchangdao at gmail.com> wrote: > I am writing a miner of crypto

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:

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

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

On Wed, Oct 3, 2012 at 1:19 AM, Jim Grosbach <grosbach at apple.com> wrote: > What's the use case? the use case is that we can print out the assembly using alternative dialect. currently, on Intel machine, the default dialect is AT&T, and we cannot change that to Intel syntax without using cl:opt. the new public method lets us change the dialect without having cl:opt involved.

What's the use case? On Oct 1, 2012, at 8:33 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > currently, there is no (easy) way to set the AssemblerDialect. the > only method i am aware of is to set that via cl:opt. > > this patch fixes that by adding a public function > setAssemblerDialect() to class MCAsmInfo. > > Signed-off-by: Jun Koi <junkoi2004 at

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

On Thu, Oct 18, 2012 at 5:33 PM, Duncan Sands <baldrick at free.fr> wrote: > 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

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

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

In principle, transform passes are not responsible to inspect @yyy is not aliased to @XXX. I guess "opt -basicaa -{any-transform-passes}" would help you. You may also try "opt -{any-analysis-passes} -aa-eval}" Note, opt is the tool not for users but for developers. He does not invoke unspecified passes automatically. ...Takumi 2012/8/11 Jun Koi <junkoi2004 at

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

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? >> >> The correct solution is to fix the LLVM build to install the .cmake files in a location that

currently, there is no (easy) way to set the AssemblerDialect. the only method i am aware of is to set that via cl:opt. this patch fixes that by adding a public function setAssemblerDialect() to class MCAsmInfo. Signed-off-by: Jun Koi <junkoi2004 at gmail.com> diff --git a/include/llvm/MC/MCAsmInfo.h b/include/llvm/MC/MCAsmInfo.h index 97aad71..cd08a7e 100644 ---

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

Hello Daniel, At the moment we are preparing the patch for disassembling microMIPS 16 bit instructions and it will be on Phabricator tomorrow or on Wednesday. Functionality is implemented in MipsDisassembler::getInstruction where first two bytes are read and decodeInstruction is called with DecoderTableMicroMips16 and only if it fails we read 4 bytes and call decodeInstruction with

forgot to mention: this is from file MipsGenDisassemblerTables.inc thanks. On Fri, Aug 23, 2013 at 2:12 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > hi, > > there are two arrays named DecoderTable32[] and DecoderTable16[] that has > no reference to. any idea why they are there? does it make sense to remove > them? > > (this is llvm 3.3) > > thanks, > Jun

On Sat, Aug 11, 2012 at 7:42 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > hi, > > i am trying to optimize the below code, in one of my LLVM functions: > > .... > store i32 96, i32* @XXX, align 4 ; (1) > store i32 117, i32* @yyy, align 4 ; (2) > store i32 31, i32* @XXX, align 4 ; (3) > .... > > naturally, optimize passes should remove the