similar to: [LLVMdev] Whither exceptions

Displaying 20 results from an estimated 30000 matches similar to: "[LLVMdev] Whither exceptions"

2007 Dec 20
0
[LLVMdev] Whither exceptions
Hi Dale, > Chris would like to turn on -enable-eh rather than -enable-correct-eh- > support in the llvm testsuite for those targets that support it.  The   > following patch is intended to turn it on for x86 and ppc.  Anton,   > Duncan, are you OK with this? yes, though see below. > Chris would also like to discuss renaming the EH command line   > options, and I have to agree
2007 Dec 20
3
[LLVMdev] Whither exceptions
On Thu, 20 Dec 2007, Duncan Sands wrote: > Hi Dale, >> If these were visible to end users I would not like exposing sjlj, an   >> implementation detail; however my understanding is that they aren't.   >> On the basis that they're intended for use by llvm geeks, I think   >> either of these is an improvement, except in the second case I think   >> the
2007 Dec 20
0
[LLVMdev] Whither exceptions
On Dec 20, 2007, at 9:47 AM, Chris Lattner wrote: > On Thu, 20 Dec 2007, Duncan Sands wrote: >> Hi Dale, >>> If these were visible to end users I would not like exposing sjlj, >>> an >>> implementation detail; however my understanding is that they >>> aren't. On the basis that they're intended for use by llvm >>> geeks, I think
2009 Feb 17
3
[LLVMdev] sjlj-exceptions handlying
On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: > Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of > an exception object (eh.exception) and an intrinsic for matching the > exception against a list of typeinfo objects (eh.selector). These > get morphed into calls to the gcc unwinder lib by the code generator. > Can sj/lj follow a similar scheme? Don't see
2007 Dec 20
0
[LLVMdev] Whither exceptions
On Dec 20, 2007, at 9:57 AM, Chris Lattner wrote: > On Thu, 20 Dec 2007, Dale Johannesen wrote: >> I'm strongly of the opinion that you shouldn't have to say anything >> to >> get EH on targets where it works. >> -fexceptions is set up like that. > > I'm not sure I get what you mean. gcc defaults to no EH data, you > need > -fexceptions to
2007 Dec 20
3
[LLVMdev] Whither exceptions
On Thu, 20 Dec 2007, Dale Johannesen wrote: > I'm strongly of the opinion that you shouldn't have to say anything to > get EH on targets where it works. > -fexceptions is set up like that. I'm not sure I get what you mean. gcc defaults to no EH data, you need -fexceptions to turn it on. g++ defaults it to on, because it knows the front-end. You think we should have llc
2009 Apr 21
6
[LLVMdev] ARM and lowerinvoke
All, I'm looking at the lowerinvoke pass as a starting point for getting SJLJ based exception handling working on ARM, but am having some troubles with it. When I run a simple testcase (attached) through llc and specify -enable-correct-eh-support, llc asserts on me. It appears there's been some bitrot somewhere. SelectDAGBuild and SelectionDAGISel cooperate to track landing pads
2007 Dec 20
0
[LLVMdev] Whither exceptions
Dale, > Chris would like to turn on -enable-eh rather than > -enable-correct-eh- > support in the llvm testsuite for those targets that support it. The > following patch is intended to turn it on for x86 and ppc. Anton, > Duncan, are you OK with this? Yes, looks obvious :) > If these were visible to end users I would not like exposing sjlj, an > implementation detail;
2013 Jul 12
2
[LLVMdev] setjmp/longjmp exception handling: how?
Dear list, I want to add SJLJ exception handling to my frontend. Unfortunately, there doesn't seem to be any examples in the documentation as to how to use the intrinsics @llvm.eh.sjlj.setjmp @llvm.eh.sjlj.longjmp @llvm.eh.sjlj.lsda @llvm.eh.sjlj.callsite Is there a way to force Clang to use SJLJ exception handling for C++? That way I would be able to look at its output to learn how to use
2009 Apr 22
0
[LLVMdev] ARM and lowerinvoke
Hi Jim, > I'm looking at the lowerinvoke pass as a starting point for getting > SJLJ based exception handling working on ARM, but am having some > troubles with it. When I run a simple testcase (attached) through llc > and specify -enable-correct-eh-support, llc asserts on me. It appears > there's been some bitrot somewhere. SelectDAGBuild and >
2009 Feb 17
0
[LLVMdev] sjlj-exceptions handlying
On Tuesday 17 February 2009 18:04:43 Mike Stump wrote: > On Feb 17, 2009, at 8:59 AM, Duncan Sands wrote: > > Excellent! To handle dwarf eh, LLVM has an intrinsic to get hold of > > an exception object (eh.exception) and an intrinsic for matching the > > exception against a list of typeinfo objects (eh.selector). These > > get morphed into calls to the gcc unwinder lib
2013 Feb 11
1
[LLVMdev] Platform-independent Exception Handling
Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote: > As far as which OS/architectures support zero-cost EH and which > support SJLJ, LLVM is designed to assume that Intel supports zero-cost > exceptions and ARM supports SjLj exceptions. However, it's all in the > personality function
2009 Apr 21
0
[LLVMdev] ARM and lowerinvoke
Hello, Jim > -enable-correct-eh-support, llc asserts on me. It appears there's been some > bitrot somewhere. Well, correct. Because many places expects exceptions to be dwarf-style. > Is it reasonable to expect that lowerinvoke is a good place to start for > doing what I'm after? I really don't think so. Since you're trying to map dwarf-based structures into sjlj
2009 May 07
2
[LLVMdev] the different semantics between dwarf-eh and sjlj-eh
Hi, >> from the exist llvm-ir it seems there are some common info for sjlj-eh >> and dwarf-eh! >> are there possible use the exist llvm-ir to generate exception table > >for sjlj-eh ? >No. There should be support from llvm-gcc. sjlj eh and dwarf eh have >different semantics different semantics ? ! I think llvm-gcc generate the IR should not include the exception
2014 Mar 19
4
[LLVMdev] Unwind, exception handling, debuggers and profilers
Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from
2014 Mar 08
2
[LLVMdev] Is LowerInvoke's "-enable-correct-eh-support" option unused?
On 6 March 2014 18:09, Mark Seaborn <mseaborn at chromium.org> wrote: > LowerAtomic "lowers atomic intrinsics to non-atomic form for use in a > known non-preemptible environment". LowerInvoke strips out exception > handling by converting invokes to calls, so that landingpads, resumes, etc. > become dead and can be removed by a later pass. > > (As an aside,
2009 May 06
2
[LLVMdev] SJLJ EH
Hi, >There's definitely more to it than the current intrinsics, which are >there to support dwarf. that's to say we need modify the llvm-gcc so the front end can generate the sjlj-style IR, >SJLJ exceptions rely on runtime library >functions to register and unregister call frames which require >unwinding, so we need to modify LLVM to handle generating those call my
2009 May 05
1
[LLVMdev] how to resolve llvm exception IR?
hi, I'm doing to make llvm backend support sjlj-eh! I have try to use the llvm-IR to generate the sjlj-eh code, but I'm totally despair ! my major problem is that llvm-ir , I mean exception instrinstics are enough for codegen the sjlj-eh code? May I need to modify the llvm-gcc ? or someone can give some advice about llvm-backend 's support sjlj-eh ? best regards
2013 Jul 12
0
[LLVMdev] setjmp/longjmp exception handling: how?
I strongly advise you not to use SjLj exception handling. Use zero-cost-exceptions via DWARF instead. If you really want to pursue sjlj anyway, look at the ARM backend. It uses them for darwin targets. -Jim On Jul 12, 2013, at 9:09 AM, Nicolas Ojeda Bar <N.Ojeda.Bar at dpmms.cam.ac.uk> wrote: > Dear list, > > I want to add SJLJ exception handling to my frontend. Unfortunately,
2010 Sep 26
0
[LLVMdev] LLVM Exception Handling
On 26 September 2010 20:13, Nathan Jeffords <blunted2night at gmail.com> wrote: > I believe the perceived problem with using eh.exception is that > is disassociates the source of the value with the invoke instruction that > generated it. As far as reusing the landing pad, that is still possible, it > would just require a phi node in the landing pad to bring all the different >