similar to: [LLVMdev] opt + fastcc bug?

On Wed, Apr 6, 2011 at 10:48 PM, Nicolas Ojeda Bar <nojb at math.harvard.edu> wrote: > Hi, > > Is this correct behaviour? > > test.ll: > > declare {} @__ex__print_int(i64) > > define i32 @main() { > entry: >  %0 = call i64 @f.1() >  %1 = call {} @__ex__print_int(i64 %0) >  ret i32 0 > } > > define internal fastcc i64 @f.1() { > entry: >

Hello, I am writing a compiler for a functional language and am using the fastcc calling convention extensibly. I am now thinking about how to implement exception handling (about which I know close to nothing) and was hoping to use the support for exception handling built-in llvm. Question: can I use the standard __cxa_throw (and personality function) from C++ and the llvm eh machinery even if

I've been struggling for several days, trying to get native exceptions to work in my code. I managed to boil down the IR to the simplest possible example that I can think of. If anyone on this list can tell me what changes I need to make to the following code to get it to work (i.e. return 0 instead of a bus error), it would make my life immensely better. ; ModuleID =

Hi Talin, You're not using the llvm intrinsics for exception handling, so your code won't work. Using _Unwind_RaiseException should be OK, but your main function must at least use llvm.eh.exception, llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. Nicolas Talin wrote: > I've been struggling for several days, trying to get native exceptions > to

Hello, I am running a i7 MacBook Pro 2011. If I write: @g = global double 0.000000e+00 define i32 @main() { entry: %0 = load double* @g %1 = fmul double 1.000000e+06, %0 store double %1, double* @g ret i32 0 } in test.ll and I run > llc test.ll > gcc test.s I get: test.s:12:no such instruction: `vmovsd _g(%rip), %xmm0' test.s:13:no such instruction: `vmulsd LCPI0_0(%rip),

Hi, It looks like PDT.getRootNode() returns NULL for: define fastcc void @c974001__lengthy_calculation. 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { entry: br label %bb bb: br label %bb } Isn't it a bug in PostDominatorTree? Please note that this crashes: opt -postdomtree -debug dom_crash.bc I think this should be reported as a bug, -Jakub On Sep 3, 2009, at

Jakub Staszak wrote: > Hi, > > It looks like PDT.getRootNode() returns NULL for: > > define fastcc void @c974001__lengthy_calculation. > 1736(%struct.FRAME.c974001* nocapture %CHAIN.185) noreturn { > entry: > br label %bb > > bb: > br label %bb > } > > > Isn't it a bug in PostDominatorTree? > > Please note that this crashes: >

Hello, Bug is already fixed by Chris (see: http://llvm.org/bugs/show_bug.cgi?id=4915) . I added getRootNode() == NULL condition to my patch. It's not a great solution, but it is enough for now I think. New patch attached. -Jakub -------------- next part -------------- A non-text attachment was scrubbed... Name: dse_ssu-2.patch Type: application/octet-stream Size: 17762 bytes Desc: not

Nicolas Geoffray wrote: > Hi Talin, > > You're not using the llvm intrinsics for exception handling, so your > code won't work. Using _Unwind_RaiseException should be OK, but your > main function must at least use llvm.eh.exception, > llvm.eh.selector.i32/64 and probably __cxa_begin_catch and __cxa_end_catch. > Let me ask a follow-up question then - if the

On Friday 13 November 2009 16:26:01 Chris Lattner wrote: > On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: > >> Point 4 is the one that caused me trouble for some time. > >> Unfortunately > >> it causes a bad interaction with the optimiser, specifically the > >> 'simplifycfg' pass. What seems to happen is that since the function > >> you are

On Friday 13 November 2009 04:57:43 David Terei wrote: > I've run into some issues with tail calls in the past, make sure you > are doing the following: > > 1. Call should be marked with tail (obviously) > 2. Next statement after tail call should be 'return void' > 3. Use fast call convention for tail calls > 4. Make sure the function you are calling doesn't

On Nov 13, 2009, at 3:34 AM, Jon Harrop wrote: >> Point 4 is the one that caused me trouble for some time. >> Unfortunately >> it causes a bad interaction with the optimiser, specifically the >> 'simplifycfg' pass. What seems to happen is that since the function >> you are calling is marked with 'noreturn', the simplifycfg pass will >> then

Er... Sending this to the list instead of the parent... On Thu, Nov 19, 2009 at 4:49 AM, Hans Wennborg <hans at hanshq.net> wrote: > Yesterday I realised that if a Function has the calling convention set > to "fast", then it is a bad idea to call it through the function pointer > one gets from ExecutionEngine::getPointerToFunction(). > > The problem is that when

On Mon, Jun 19, 2017 at 12:06 PM, Mehdi AMINI <joker.eph at gmail.com> wrote: > Hi, > > 2017-06-19 8:45 GMT-07:00 Andrew Kelley via llvm-dev < > llvm-dev at lists.llvm.org>: > >> Greetings, >> >> I have a Zig implementation of ceil which is emitted into LLVM IR like >> this: >> >> ; Function Attrs: nobuiltin nounwind >> define

Two related questions. This is with LLVM 2.4 doing a JIT compile to x86-64. (I generate LLVM IR using an IRBuilder instance, compile/optimize, and then call getPointerToFunction() to get a "native" function pointer.) (1) My reading of various mailing list messages seems to indicate that a function marked as using the "fastcc" calling convention

Below is attached a full IR module that can reproduce this issue, but the part to notice is this: %Foo96Bits = type <{ i24, i24, i24, i24 }> define internal fastcc i16 @main.0.1() unnamed_addr #2 !dbg !113 { Entry: %value = alloca %Foo96Bits, align 1 %b = alloca i24, align 4 %0 = bitcast %Foo96Bits* %value to i8*, !dbg !129 call void @llvm.memcpy.p0i8.p0i8.i64(i8* %0, i8* bitcast

On Thu, Nov 19, 2009 at 12:45 PM, Samuel Crow <samuraileumas at yahoo.com> wrote: > > > > > ----- Original Message ---- >> From: Kenneth Uildriks <kennethuil at gmail.com> >> To: Samuel Crow <samuraileumas at yahoo.com> >> Cc: OvermindDL1 <overminddl1 at gmail.com>; LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> >> Sent:

On Thu, Feb 12, 2009 at 5:34 PM, Jeff Kuskin <jk500500 at yahoo.com> wrote: > Two related questions. > (2) Why does the x86-64 JIT backend generate a "ret $0x8" instruction > to return from a fastcc function that is (a) marked as fastcc > (CallingConv::Fast); but (b) takes no arguments and returns 'void'? fastcc generated code ends with this: > c20800

On OSX I thought I'd try to optimize my compiler a bit by switching some of the calling conventions from CCallingConv to FastCC. The compiler ran fine, but when I executed the code, I got "Bad Instruction 4". I'm seeing some other mentions on this mailing list of issues like this on OSX (I'm using 10.8). Is there anything I need to change to enable fastcc with my compiler? I

----- Original Message ---- > From: OvermindDL1 <overminddl1 at gmail.com> > To: LLVM Developers Mailing List <llvmdev at cs.uiuc.edu> > Sent: Thu, November 19, 2009 6:12:47 AM > Subject: Re: [LLVMdev] fastcc and ExecutionEngine::getPointerToFunction() > > Er... Sending this to the list instead of the parent... > > On Thu, Nov 19, 2009 at 4:49 AM, Hans