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? -------------- next part -------------- A non-text attachment was scrubbed... Name: mf.patch Type: application/octet-stream Size: 669 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20071219/4400da47/attachment.obj> -------------- next part -------------- Chris would also like to discuss renaming the EH command line options, and I have to agree it's not obvious what they do. He had a couple of ideas:> rename -enable-correct-eh-support to -enable-sjlj-exceptions or > something> Maybe a better interface would be -eh-model={sjlj,dwarf,none} with > none being the default?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?
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 it's not obvious what they do. > He had a couple of ideas: > > > rename -enable-correct-eh-support to -enable-sjlj-exceptions or > > something > > > > Maybe a better interface would be -eh-model={sjlj,dwarf,none} with > > none being the default? > > 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. Since LowerInvoke can result in costly code, add a -disable-eh-emulation option (more or less equivalent to the opposite of -enable-correct-eh-support) which causes the LowerInvoke pass not to do anything (like !-enable-correct-eh-support does). This way, if you turn on -enable-eh then you get some kind of eh support on all targets (emulated using sj/lj if the target does not 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. Ciao, Duncan.
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/