search for: llabel1

...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, %rsp ret .size f, .-f .Leh_func_end1: .section .gcc_except_table,"a", at progbits .al...

...; .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, %rsp > ret &gt...

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

...n 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: >>...

...t; Only one was deleted. Consider the code: define i32 @test(i32 %argc) { entry: %tmp2 = sdiv 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:...

...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 in X86InstrInfo.td? movsd %xmm0, -8(%rbp) # ??? what insn in X86In...

...zed uleb128 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_be...

...ioned > *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 in X86InstrInfo.td? > movsd %xmm0, -8(%rbp)...

...# @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, .-main .Leh_func_end2: --- Even this monkey (thinks he) can see the constant 6 being passed to foo in %edi. So far so good. Now I tried to get it to inline, without much luck. Putting together everything I tried into one test, I change...

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

...a. The first movl after the two addl is using a wrong address to store the result (%esp points to %dummy, but the result should not be stored there). ------------------------------------------------------------------------ .text .align 16 .def _tmp; .scl 3; .type 32; .endef _tmp: pushl %ebp Llabel1: movl %esp, %ebp Llabel2: pushl %ebx pushl %edi pushl %esi subl $4, %esp LBB1_1: # entry2 movl $8, %esi movl %esi, %eax call __alloca movl %esp, %edi movl %esi, %eax call __alloca movl %esp, %ebx movl %esi, %eax call __alloca movl %esp, -16(%ebp) movl %esi, %eax call __alloca movl...

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

On 2009-02-24 12:35, Jon Harrop wrote: > On Tuesday 24 February 2009 00:16:37 Dan Gohman wrote: > >> On Feb 23, 2009, at 5:59 AM, Anton Korobeynikov wrote: >> >>> This is not true in general and highly target- and CC- dependent. For >>> example, you can ran out of registers and then your struct can be >>> passed >>> partly in registers

...di_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 in X86InstrInfo.td? >>...

On Tuesday 24 February 2009 00:16:37 Dan Gohman wrote: > On Feb 23, 2009, at 5:59 AM, Anton Korobeynikov wrote: > > This is not true in general and highly target- and CC- dependent. For > > example, you can ran out of registers and then your struct can be > > passed > > partly in registers and partly on stack. And depending on the stack > > frame size of the callee

...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 push another stack fr...

Gordon Henriksen wrote: > The intrinsics are entirely neutral to collector implementation, and > thus to threading. They could easily be used to implement reference > counting, for instance, which may or may not be implemented in a > threadsafe manner. However, as with your algorithm, reference counting > does not require code generator support, and so would not justify the

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() {