search for: movsbl

...milarly whether return values should be sign extended by the caller or callee. Consider a simple 'signed char' division routine: signed char sdiv(signed char x, signed char y) { return x / y; } On my Fedora 16 Linux host GCC 4.6.2 produces: sdiv: .LFB11: .cfi_startproc movsbl %dil, %eax movsbl %sil, %esi movl %eax, %edx sarl $31, %edx idivl %esi ret where as clang 2.9 produces: sdiv: # @sdiv .Leh_func_begin0: # BB#0: movl %edi, %eax cltd idivl %esi...

...y) @@ -725,6 +725,8 @@ { 0x2, {0xFF, 0x00}, {0x89, 0x00} }, // mov r/m32,r32 or r/m16,r16 { 0x3, {0xFF, 0xFF, 0xFF}, {0x49, 0x89, 0xF8} }, // mov %rdi,%r8 { 0x4, {0xFF, 0xFF, 0xFF, 0xFF}, {0x40, 0x0F, 0xBE, 0xCE} }, // movsbl %sil,%ecx + { 0x7, {0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00}, + {0x48, 0x8D, 0x05, 0x00, 0x00, 0x00, 0x00} }, // lea $imm(%rip),%rax { 0x3, {0xFF, 0xFF, 0xFF}, {0x0F, 0xBE, 0xCE} }, // movsbl, %dh, %ecx { 0x3, {0xFF, 0xFF, 0x00}, {0xFF, 0x77, 0x00} }, // p...

...ect, but the final code generated by llvm is not correct. Check the assembly code below: the add instruction should be addl %eax, %ecs main: subl $12, %esp fnstcw 10(%esp) movb $2, 11(%esp) fldcw 10(%esp) movl 20(%esp), %eax movl (%eax), %eax movsbl (%eax), %ecx movsbl 1(%eax), %eax addl %ecx, %ecx imull %ecx, %eax movl %eax, 4(%esp) movl $.str_1, (%esp) call printf #IMPLICIT_DEF %eax addl $12, %esp ret .size main, .-main On the other hand, if I use the TwoAddress...

...> or callee. > > Consider a simple 'signed char' division routine: > > signed char sdiv(signed char x, signed char y) > { >  return x / y; > } > > On my Fedora 16 Linux host GCC 4.6.2 produces: > > sdiv: > .LFB11: >        .cfi_startproc >        movsbl  %dil, %eax >        movsbl  %sil, %esi >        movl    %eax, %edx >        sarl    $31, %edx >        idivl   %esi >        ret > > where as clang 2.9 produces: > > sdiv:                                   # @sdiv > .Leh_func_begin0: > # BB#0: >        movl    %...

...y just replacing them with two spaces everywhere. > > That will cause some really ugly output; can a somewhat more intelligent formatter be used to keep columns aligned? > Here's how some random output currently looks in a 2-space-per-tab editor: cmpl $0, -28(%rbp) je .LBB2_9 movsbl -81(%rbp), %eax movq -16(%rbp), %rcx movb 56(%rcx), %dl andb $1, %dl movzbl %dl, %esi So if you're worried about ugliness, it's already there :-) Eli

I'm struggling to explain an ASAN report I'm now getting that I didn't get previously on the same code. In fact the report only happens with -O2 and not when I remove the -O flags which makes it hard to debug and makes me suspect it's dependent on exactly which instructions the code generation decides to access the bytes involved. Afaict the C code shouldn't be accessing the

.... > > > > That will cause some really ugly output; can a somewhat more intelligent > formatter be used to keep columns aligned? > > > > Here's how some random output currently looks in a 2-space-per-tab editor: > > cmpl $0, -28(%rbp) > je .LBB2_9 > movsbl -81(%rbp), %eax > movq -16(%rbp), %rcx > movb 56(%rcx), %dl > andb $1, %dl > movzbl %dl, %esi > > So if you're worried about ugliness, it's already there :-) > > Eli > _______________________________________________ > LLVM Developers mailing list &...

...) 0xb7c2708a <+42>: jmp 0xb7c270b1 <main+81> 0xb7c2708c <+44>: mov 0x10(%esp),%eax 0xb7c27090 <+48>: mov 0x4(%eax),%eax 0xb7c27093 <+51>: mov (%eax),%al 0xb7c27095 <+53>: mov %al,0xf(%esp) 0xb7c27099 <+57>: movsbl 0xf(%esp),%eax 0xb7c2709e <+62>: add $0xffffffd0,%eax 0xb7c270a1 <+65>: mov %eax,(%esp) 0xb7c270a4 <+68>: call 0xb7c27010 <compute_factorial> 0xb7c270a9 <+73>: mov %eax,0x8(%esp) 0xb7c270ad <+77>: mov %eax,0x18(%esp)...

> From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Eli Bendersky > Subject: [LLVMdev] Getting rid of tabs in LLVM's assembly output? > Problem: I then get tabs in my tests, which are discouraged by LLVM's > own code standards, because assembly output uses tabs extensively. > Proposal: get rid of tabs by just replacing them with

...artialRegisterOperationsTestChar: # @PartialRegisterOperationsTestChar # BB#0: # %entry movb 16(%esp), %dl movb 8(%esp), %al mulb 4(%esp) movb %al, %cl movb %dl, %al mulb 12(%esp) addb %cl, %al movsbl %al, %eax ret I am interested in learning how to change the 8-bit variables in PartialRegisterOperationsTestChar to use 32-bit registers. However, I am new to LLVM and not sure how to do this. I've been trying to find where the mov esp->reg instructions are generated but I haven'...

Scenario: sometimes when creating tests for MC, I run llc, take its assembly (.s) output and copy-paste parts of it into a test. Problem: I then get tabs in my tests, which are discouraged by LLVM's own code standards, because assembly output uses tabs extensively. Proposal: get rid of tabs by just replacing them with two spaces everywhere. I had an informal chat about this with Jim on the

...3f800000 00000000 00000000 00000000 > 0x0177fc60: 00000000 00000000 00000000 00000000 > 0x0177fc70: 00000000 00000000 00000000 00000000 > Backtrace: > =>1 0x004dd5a3 in gta_sa (+0xdd5a3) (0x7ed440f0) > 2 0x000248ec (0x81e58955) > 3 0x00000000 (0x00000000) > 0x004dd5a3: movsbl 0x0(%ecx,%eax,1),%edx > Modules: > Module Address Debug info Name (106 modules) > PE 240000- 249000 Deferred ogg > PE 250000- 358000 Deferred vorbis > PE 360000- 390000 Deferred eax > PE 400000- 1577000 Export gta_sa > PE 10000000-1001...

Hi there, I wondered whether anyone could give me any advice about counting assembly instructions when using MCJIT? For performance regression testing I would like to be able to count the number of instructions generated during the jit compilation of a given module. The Statistic class, as far as I understand, cannot collect this data per-module (per-ExecutionEngine/per-MCJIT), and there is

I got a qemu crash and errors reported in bochs while trying to get latest core32 branch working (pxelinux): qemu: fatal: Trying to execute code outside RAM or ROM at 0xe6e8aa07 EAX=6e0c7811 EBX=000034b3 ECX=ca68b338 EDX=00000048 ESI=750e3fff EDI=00000020 EBP=d07e4988 ESP=00102324 EIP=e6e8aa07 EFL=00000002 [-------] CPL=0 II=0 A20=1 SMM=0 HLT=0 ES =0028 00000000 ffffffff 00cf9300 CS =0020

On 31.05.2011 19:45, Devang Patel wrote: > > On May 31, 2011, at 10:36 AM, trash-stuff at gmx.de > <mailto:trash-stuff at gmx.de> wrote: > >> On 31.05.2011 19:22, Devang Patel wrote: >>> >>> On May 30, 2011, at 11:11 AM,trash-stuff at gmx.de >>> <mailto:trash-stuff at gmx.de>wrote: >>> >>>> Hi all, >>>>