search for: leh_func_begin1

...eh table, and has the personality function recorded in the CIE. This is with llc from top-of-tree. Do you see something different? Ciao, Duncan. .file "selector.ll" .text .align 16 .globl f .type f, at function f: # @f .Leh_func_begin1: # BB#0: # %e subq $8, %rsp .Llabel4: .Llabel1: callq g .Llabel2: # BB#1: # %c addq $8, %rsp ret .LBB1_2: # %u .Llabel3: addq $8,...

...x86-64 assembler for my function including eh table is: .text .align 16 .globl _ZN4N0014Main5test5EN2IO6WriterEiA_l .type _ZN4N0014Main5test5EN2IO6WriterEiA_l, at function _ZN4N0014Main5test5EN2IO6WriterEiA_l: # @_ZN4N0014Main5test5EN2IO6WriterEiA_l .Leh_func_begin153: .Lfunc_begin153: .LBB153_0: # %entry subq $56, %rsp .Llabel294: .LBB153_1: movq %rdi, 24(%rsp) movq %rsi, 48(%rsp) movl %edx, 44(%rsp) movq %rcx, 32(%rsp) .LBB153_2:...

Hi, I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. I've been trying to get a minimal test function to work, which simply invokes

...s relevant. > > > .text > .align 16 > .globl _ZN4N0014Main5test5EN2IO6WriterEiA_l > .type _ZN4N0014Main5test5EN2IO6WriterEiA_l, at function > _ZN4N0014Main5test5EN2IO6WriterEiA_l: # > @_ZN4N0014Main5test5EN2IO6WriterEiA_l > .Leh_func_begin153: > .Lfunc_begin153: > .LBB153_0: # %entry > subq $56, %rsp > .Llabel294: > > .LBB153_1: > movq %rdi, 24(%rsp) > movq %rsi, 48(%rsp) > movl %edx, 44(%rsp) > movq %rcx, 32(%rsp) > .L...

...uot;); } }; static void inline_me(void) { Cleanup C; throw 0; } int main(void) { try { inline_me(); } catch (...) { printf("in catch all\n"); } return 0; } (assume it's all been inlined), the EH handling table for "main" goes from Leh_func_begin1 to Leh_func_end1, marking off each region whether it can throw or not. From my reading of the Exception Tables documentation, this is unnecessary – at least for C++. If a call throws and it doesn't have an entry in the unwind table, then the "terminate()" function is called. I...

...7, 8 ret # 25 return_internal [length = 1] .cfi_endproc Now I may look into config/i386/i386.md, and look for mentioned *pushdi2_rex64, movdi_1_rex64, floatdidf2_sse_interunit and other patterns and study how they work. How to make the same annotation for clang output assembler code? test: .Leh_func_begin1: pushq %rbp # ??? what insn in X86InstrInfo.td? .Llabel1: movq %rsp, %rbp # ??? what insn in X86InstrInfo.td? .Llabel2: movq %rdi, -16(%rbp) # ??? what insn in X86InstrInfo.td? movq -16(%rbp), %rax # ??? what insn in X86InstrInfo.td? cvtsi2sdq %rax, %xmm0 # ??? what insn i...

Hi Bill, > Right now we generate call sites for all of the code in a function, > even for code that cannot (or at least shouldn't) throw an exception. ... > (assume it's all been inlined), the EH handling table for "main" goes > from Leh_func_begin1 to Leh_func_end1, marking off each region whether > it can throw or not. From my reading of the Exception Tables > documentation, this is unnecessary – at least for C++. If a call > throws and it doesn't have an entry in the unwind table, then the > "terminate()" f...

...128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: .section __DATA,__gcc_except_tab .align 2 GCC_except_table1: .byte 0x0 .byte 0x0 .byte 0x0 Lexception1: .byte 0xFF .byte 0x0 .byte 0x26 .byte 0x3 .byte 0x1A .set Lset1eh,Llabel1-Leh_func_begin1 .long Lset1eh Use: .section __DATA,__gcc_except_tab .align 2 GCC_except_table1: Lexception1: .byte 0xFF .byte 0x0 .byte 0x26 .byte 0x3 .byte 0x9A, 0x80, 0x80, 0x00 # This is 26 in uleb128 with leading zeros to pad it out to 4 bytes .set Lset1eh,Llabel1-Leh_func_begin1 .long Lset...

...; .cfi_endproc > > Now I may look into config/i386/i386.md, and look for mentioned > *pushdi2_rex64, movdi_1_rex64, floatdidf2_sse_interunit and other > patterns and study how they work. > > How to make the same annotation for clang output assembler code? > > test: > .Leh_func_begin1: > pushq %rbp # ??? what insn in X86InstrInfo.td? > .Llabel1: > movq %rsp, %rbp # ??? what insn in X86InstrInfo.td? > .Llabel2: > movq %rdi, -16(%rbp) # ??? what insn in X86InstrInfo.td? > movq -16(%rbp), %rax # ??? what insn in X86InstrInfo.td? > cvtsi2sdq...

...cts/Nil/nil(0)$ ./testInline ; echo $? 42 gemini:~/Projects/Nil/nil(0)$ and the generated assembly (with much red tape snipped for now): --- .file "testInline.bc" .text .align 16 .globl foo .type foo, at function foo: # @foo .Leh_func_begin1: .LBB1_0: imull $7, %edi, %eax ret .size foo, .-foo .Leh_func_end1: .align 16 .globl main .type main, at function main: # @main .Leh_func_begin2: .LBB2_0: subq $8, %rsp .Llabel1: movl $6, %edi call foo addq $8, %rsp ret .size main,...

...v i32 2, %argc to label %continue unwind to label %unwindblock ; <i32> [#uses=1] continue: ret i32 %tmp2 unwindblock: unwind } And here is the resulting x86 code (Llabel1 was supposed to be before the {ctld, idvl} and Llabel2 which was after is not generated) test: .Leh_func_begin1: .Llabel4: movl $2, %eax movl 4(%esp), %ecx cltd idivl %ecx .Llabel1: .LBB1_1: # continue ret .LBB1_2: # unwindblock Thanks Duncan, Nicolas

...# constant pool <4 x i32> .long 1 # 0x1 .long 2 # 0x2 .long 3 # 0x3 .zero 4 .text Should this data not be loaded as is into %xmm0 like in the case of vector of four?: retFour: # @retFour .Leh_func_begin1: # BB#0: movaps .LCPI1_0, %xmm0 ret This would of course leave the responsibility of ignoring the 4th lane to the caller. Debugging the code generation, I notice that the v3i32 is widened to v4i32, but when X86TargetLowering::CanLowerReturn, the v3i32 is seems to be split up into three MVT::...

...es1 %10 = phi i64 [ %5, %if.yes1 ], [ %9, %if.no2 ] br label %if.after } LLVM generates the following assembly, seemingly applying tail call optimization even though the ret instruction does not follow the tail call instruction: <snip> _ack.15: ## @ack.15 Leh_func_begin1: ## BB#0: ## %entry pushq %rbx Ltmp1: Ltmp2: testq %rdi, %rdi jle LBB1_3 ## BB#1: ## %if.no movq %rdi, %rbx testq %rsi, %rsi jle LBB1_4 ## BB#2: ## %if.no2 decq %rsi movq %rbx, %rdi callq _ack.15...

...Now I may look into config/i386/i386.md, and look for mentioned >> *pushdi2_rex64, movdi_1_rex64, floatdidf2_sse_interunit and other >> patterns and study how they work. >> >> How to make the same annotation for clang output assembler code? >> >> test: >> .Leh_func_begin1: >>  pushq %rbp          # ??? what insn in X86InstrInfo.td? >> .Llabel1: >>  movq  %rsp, %rbp  # ??? what insn in X86InstrInfo.td? >> .Llabel2: >>  movq  %rdi, -16(%rbp)  # ??? what insn in X86InstrInfo.td? >>  movq  -16(%rbp), %rax  # ??? what insn in X86InstrI...

...got a > segmentation fault. It looks good to me. Can someone help me out or is > this a bug? > Marc, I tried the exact same example as you did, and got the same issue. If you look at the generated x86 machine code, it looks like unwind is compiled into nothing at all: > foo: > .Leh_func_begin1: > > .Llabel1: > .size foo, .-foo > .Leh_func_end1: > (Note that there isn't even a return instruction). This means your execution just falls through into the following function without unwinding its own stack frame. In the above example, this causes it to fall into main and...

Hi Nicolas, > In order to have exceptions for non-call instructions (such as sdiv, > load or stores), I'm modifying codegen so that it generates a BeginLabel > and an EndLabel between the "may throwing" instruction. This is what the > codegen of an InvokeInst does. the rule is that all instructions between eh begin labelN and eh end labelN must unwind to the same

Can anyone tell me if invoke/unwind is stable in 2.3? I'm seeing some really weird stuff -- unwinds are ending up in seemingly arbitrary places... definitely not inside the caller's unwind block My target is x86. As a simple test, I tried to compile the following code and I got a segmentation fault. It looks good to me. Can someone help me out or is this a bug? define i32 @foo() {

Hi everyone, In order to have exceptions for non-call instructions (such as sdiv, load or stores), I'm modifying codegen so that it generates a BeginLabel and an EndLabel between the "may throwing" instruction. This is what the codegen of an InvokeInst does. However, when generating native code, only BeginLabel is generated, and it is generated after the instruction. I'm not