search for: ltmp0

...oo(); extern void print(const char *) __attribute__((nothrow)); void bar () { try { foo(); } catch (...) { print("caught (...)\n"); } } .section __TEXT,__gcc_except_tab ... ;; CallSite Table .long Ltmp0-Leh_func_begin0 .long Ltmp1-Ltmp0 <--- this region covers the call to foo .long Ltmp2-Leh_func_begin0 .byte 1 <--- this is it's Action Table index ... ;; Action Table .byte 1...

...} return (r); } I get the following code emitted for the return if the alias line is present: LBB0_3: # %if.end movl 64(%esp), %eax movsd 24(%esp), %xmm0 movsd 32(%esp), %xmm1 movsd %xmm1, 8(%eax) movsd %xmm0, (%eax) addl $56, %esp popl %esi ret .Ltmp0: .size _lldiv, .Ltmp0-_lldiv .weak lldiv lldiv = _lldiv And this if it isn't: LBB0_3: # %if.end movl 64(%esp), %eax movsd 24(%esp), %xmm0 movsd 32(%esp), %xmm1 movsd %xmm1, 8(%eax) movsd %xmm0, (%eax) addl $56, %esp popl %esi ret $4 .Ltmp0: .size _ll...

...# @TType Encoding = udata4 .uleb128 41 # @TType base offset .byte 3 # Call site Encoding = udata4 .uleb128 39 # Call site table length .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start .long .Lset0 .Lset1 = .Ltmp0-.Leh_func_begin0 # Region length .long .Lset1 .long 0 # Landing pad .uleb128 0 # Action .Lset2 = .Ltmp0-.Leh_func_begin0 # Region start .long .Lset2 .Lset3 = .Ltmp1-.Ltmp0 # Region length .long .Ls...

...## %entry pushq %rbp Ltmp6: .cfi_def_cfa_offset 16 Ltmp7: .cfi_offset %rbp, -16 movq %rsp, %rbp Ltmp8: .cfi_def_cfa_register %rbp subq $80, %rsp leaq -8(%rbp), %rdi callq __ZN3BobC1Ev leaq -16(%rbp), %rdi callq __ZN3BobC1Ev leaq -24(%rbp), %rdi callq __ZN3BobC1Ev Ltmp0: callq __Z3foov Ltmp1: <snip> .section __TEXT,__gcc_except_tab .align 2 GCC_except_table0: Lexception0: .byte 255 ## @LPStart Encoding = omit .byte 155 ## @TType Encoding = indirect pcrel sdata4 .byte 156 ## @TType base offse...

..., __gxx_personality_v0 > .Leh_func_begin0: > .cfi_lsda 3, .Lexception0 > # BB#0: # %entry > pushq %rbx > .Ltmp6: > .cfi_def_cfa_offset 16 > .Ltmp7: > .cfi_offset %rbx, -16 > movq %rdi, %rbx > .Ltmp0: > callq *%rbx > .Ltmp1: > # BB#1: # %_Z4testPFvvE.exit > .Ltmp3: > callq *%rbx > .Ltmp4: > # BB#2: # %_Z4testPFvvE.exit3 > popq %rbx > retq > .LBB0_3:...

...> .uleb128 41 # @TType base offset > .byte 3 # Call site Encoding = udata4 > .uleb128 39 # Call site table length > .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start > .long .Lset0 > .Lset1 = .Ltmp0-.Leh_func_begin0 # Region length > .long .Lset1 > .long 0 # Landing pad > .uleb128 0 # Action > .Lset2 = .Ltmp0-.Leh_func_begin0 # Region start > .long .Lset2 > .Lset3 = .Ltmp1-.Ltmp0...

...nline asm. Clang keeps the original type of "loc" as "bool", which generates an "i1 true" after inlining. So far so good. However, during ISEL, the "true" is converted to a signed integer. So when it's evaluated, the result is this: .quad (42+(-1))-.Ltmp0 (notice the "-1"). GCC emits a positive one instead: .quad 42 + 1 - .Ltmp0 I'm not sure where the problem lies. Should the inline asm promote the "i1" to "i32" during ISEL? Should it be promoted during inlining? Is there a situation where we require the v...

...41 # @TType base offset >> .byte 3 # Call site Encoding = udata4 >> .uleb128 39 # Call site table length >> .Lset0 = .Leh_func_begin0-.Leh_func_begin0 # Region start >> .long .Lset0 >> .Lset1 = .Ltmp0-.Leh_func_begin0 # Region length >> .long .Lset1 >> .long 0 # Landing pad >> .uleb128 0 # Action >> .Lset2 = .Ltmp0-.Leh_func_begin0 # Region start >> .long .Lset2 >> .Lset3 = ....

...nbounds i32* %0, i64 2 ret i32* %arrayidx } $ llc -O3 takeaddr.ll -o - .file "takeaddr.ll" .text .globl bar .align 16, 0x90 .type bar, at function bar: # @bar # BB#0: # %entry movq %rdi, -8(%rsp) leaq 8(%rdi), %rax ret .Ltmp0: .size bar, .Ltmp0-bar .section ".note.GNU-stack","", at progbits The first instruction in "bar" is not clear. Why is it needed? It seems harmless, but does it serve any purpose? Alignment? ISTM that the leaq suffices to pefrorm the actual task of the function. Is t...

...B0_3:                                # %if.end >        movl    64(%esp), %eax >        movsd   24(%esp), %xmm0 >        movsd   32(%esp), %xmm1 >        movsd   %xmm1, 8(%eax) >        movsd   %xmm0, (%eax) >        addl    $56, %esp >        popl    %esi >        ret > .Ltmp0: >        .size   _lldiv, .Ltmp0-_lldiv > > >        .weak   lldiv > lldiv = _lldiv > > And this if it isn't: > LBB0_3:                                # %if.end >        movl    64(%esp), %eax >        movsd   24(%esp), %xmm0 >        movsd   32(%esp), %xmm1 &gt...

On Feb 17, 2012, at 12:50 AM, Ivan Llopard wrote: > Hello, > > I've added a little combining operation in DAGCombiner to fold a chain of insertelt nodes if that chain is proved to fully overwrite the very first source vector. In which case, I supposed a build_vector is better. It seems to be safe but I don't know if it is correctly implemented or if it is already done somewhere

...tly set AllowQuotesInName = false (which should be the default). Here is a shortened output example: .file "main.c" .text .global "%main" .align 4 .type "%main", at function "%main": [...] .Ltmp0: .size "%main", .Ltmp0-"%main" Is this working as intended? Because I really need to use the percent as prefix and can't have the quotes in the symbol name. Greetings, Jan -------------- next part -------------- An HTML attachment was scrubbed... URL: <http:...

...# @sample_test # BB#0: # %L.entry movl 4(%esp), %eax movss 304(%eax), %xmm0 xorps %xmm1, %xmm1 movl 8(%esp), %eax movups %xmm1, 624(%eax) pshufd $65, %xmm0, %xmm0 # xmm0 = xmm0[1,0,0,1] movdqu %xmm0, 608(%eax) ret .Ltmp0: .size sample_test, .Ltmp0-sample_test .section ".note.GNU-stack","", at progbits It seems to me that this sequence of instruction is building vector: <float 'elem_1_of_source', float 'elem_0_of_source' , float 'elem_0_of_source&...

On Jul 28, 2011, at 8:41 AM, Peter Lawrence wrote: > In short the problem is that there is an ambiguity between a cleanup handler having > an Action Table entry that looks like > .byte 1 ;; Type = 1 (ie #1 entry in Types Table) > .byte 0 ;; Next = 0 (ie none, ie this is the list terminator for this try-statement) > together with a corresponding Types Table entry #1 that looks

Hello, I've added a little combining operation in DAGCombiner to fold a chain of insertelt nodes if that chain is proved to fully overwrite the very first source vector. In which case, I supposed a build_vector is better. It seems to be safe but I don't know if it is correctly implemented or if it is already done somewhere else. Please find attached the patch. Regards, Ivan

...ion( MCInstBuilder(X86::JMP_1) .addExpr(MCSymbolRefExpr::create(Target, OutContext)), getSubtargetInfo()); EmitNops(*OutStreamer, 9, Subtarget->is64Bit(), getSubtargetInfo()); OutStreamer->EmitLabel(Target); Which turns into: .Lxray_sled_0: .palign 2, 0x90 jmp .Ltmp0 nopw 512(%rax,%rax,1) .Ltmp0: // rest of the code Is there a way of forcing the lowered JMP instruction to turn into a two-byte jump that does a short relative jump (one that fits within 8 bits)? When I run the binary and disassemble the function I'm seeing it turn into a 5-byte jump (jmpq...

Hi I use BlockAddress to get the address of BasicBlock , and I use GlobalVariable 's getInitializer() to pass the address of BasicBlock to the global variable of my own program and then I print it out. But , I found that BlockAddress is not always correct. For example, some function's rsp (stack pointer) or other register is maintained by caller, so it would be like:

...3 takeaddr.ll -o - > .file "takeaddr.ll" > .text > .globl bar > .align 16, 0x90 > .type bar, at function > bar: # @bar > # BB#0: # %entry > movq %rdi, -8(%rsp) > leaq 8(%rdi), %rax > ret > .Ltmp0: > .size bar, .Ltmp0-bar > > > .section ".note.GNU-stack","", at progbits > > The first instruction in "bar" is not clear. Why is it needed? It > seems harmless, but does it serve any purpose? Alignment? ISTM that > the leaq suffices to pefrorm...

...-o lolwut.bc ~/llc -O0 lolwut.bc -o lolwut.s ---- lolwut.s ---------------------------- .file "lolwut.bc" .text .globl lolwut .align 2 .type lolwut,%function lolwut: @ @lolwut .fnstart @ BB#0: @ %entry @APP ldr r1, .Ltmp0 .align 2 .Ltmp0: .long ".L11" ".L11": @NO_APP bx lr .Ltmp1: .size lolwut, .Ltmp1-lolwut ------------------------------------------ Somehow, the forward referenced label at 1: in the original assembly is getting mangled when its constant pool entry is created (the bad ch...

...movl %esp, %ebp movl $1, %eax movl a, %ecx .align 16, 0x90 .LBB0_1: * movl b, %edx* addl (%edx,%eax,4), %ecx movl %ecx, a incl %eax cmpl $100, %eax jne .LBB0_1 popl %ebp ret .Ltmp0: .size foo, .Ltmp0-foo .section .note.GNU-stack,"", at progbits .ident "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)" -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pip...