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 default should be target-dependent. Comments?> How about having -enable-eh turn on dwarf eh on all targets (including > those that don't support it, in which case intrinsics get lowered to > nothing much IIRC), and also have it cause a LowerInvoke pass to be run > on targets that do not support dwarf eh.This also makes sense to me. The disadvantage being that you can only access one EH model for each target this way. With -eh-model={foo} you can pick.> support dwarf eh). The testsuite can thus just use -enable-eh. If you > don't want eh at all then don't pass -enable-eh. If you only want eh > on targets that support dwarf eh then you can pass -enable-eh > -disable-eh-emulation.Ok, so it sounds like you want a way to "enable the default eh model", and I want the ability to pick for "power users". How about something like: <nothing> -> eh disabled (aka -fno-exceptions in gcc) -enable-eh -> target default -enable-eh=default -> target default -enable-eh=sjlj -enable-eh=dwarf ? -Chris -- http://nondot.org/sabre/ http://llvm.org/
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 >>> either of these is an improvement, except in the second case I think >>> the default should be target-dependent. Comments? > >> How about having -enable-eh turn on dwarf eh on all targets >> (including >> those that don't support it, in which case intrinsics get lowered to >> nothing much IIRC), and also have it cause a LowerInvoke pass to be >> run >> on targets that do not support dwarf eh. > > This also makes sense to me. The disadvantage being that you can > only access one EH model for each target this way. With -eh- > model={foo} you can pick. > >> support dwarf eh). The testsuite can thus just use -enable-eh. If >> you >> don't want eh at all then don't pass -enable-eh. If you only want eh >> on targets that support dwarf eh then you can pass -enable-eh - >> disable-eh-emulation. > > Ok, so it sounds like you want a way to "enable the default eh > model", and I want the ability to pick for "power users". How about > something like: > > <nothing> -> eh disabled (aka -fno-exceptions in gcc) > -enable-eh -> target default > -enable-eh=default -> target default > -enable-eh=sjlj > -enable-eh=dwarf > > ?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.
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 default to EH on when the target supports it? Don't all targets support sjlj? -Chris -- http://nondot.org/sabre/ http://llvm.org/
> Ok, so it sounds like you want a way to "enable the default eh model", and > I want the ability to pick for "power users". How about something like: > > <nothing> -> eh disabled (aka -fno-exceptions in gcc) > -enable-eh -> target default > -enable-eh=default -> target default > -enable-eh=sjlj > -enable-eh=dwarf > > ?Sounds good to me. D.