Whither exceptions

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Whither exceptions

Dale Johannesen
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?




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?


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

mf.patch (693 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Anton Korobeynikov
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; 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?
The -eh-model stuff also looks extremely useful for me.

--
With best regards, Anton Korobeynikov.

Faculty of Mathematics & Mechanics, Saint Petersburg State University.


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Duncan Sands-2
In reply to this post by Dale Johannesen
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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Dale Johannesen

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.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Chris Lattner
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/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Dale Johannesen

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 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?

The target and the source language, yes.  I agree it should be off by  
default
for C, so I guess what I want is to encode the -fexceptions value in  
the IR.
People with C++ programs shouldn't need a BE flag to make a fundamental
language feature work.

> Don't all targets support sjlj?

Apparently not, since there were a lot of new passes when I changed
-enable-eh-correct to -enable-eh.  I haven't looked into the sjlj  
implementation
at all though, so I can't say why.

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Chris Lattner
On Thu, 20 Dec 2007, Dale Johannesen wrote:
>> front-end.  You think we should have llc default to EH on when the
>> target supports it?
>
> The target and the source language, yes.  I agree it should be off by
> default for C, so I guess what I want is to encode the -fexceptions
> value in the IR. People with C++ programs shouldn't need a BE flag to
> make a fundamental language feature work.

That is an interesting point.  Maybe there should be a function attr that
says the function needs unwind info?  Duncan, what do you think?

>> Don't all targets support sjlj?
>
> Apparently not, since there were a lot of new passes when I changed
> -enable-eh-correct to -enable-eh.  I haven't looked into the sjlj
> implementation at all though, so I can't say why.

Ok.  I wouldn't be suprised if it was bitrotted or something, it gets
little love.

-Chris

--
http://nondot.org/sabre/
http://llvm.org/
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Duncan Sands-2
In reply to this post by Dale Johannesen
Hi,

> > 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?
>
> The target and the source language, yes.  I agree it should be off by  
> default
> for C, so I guess what I want is to encode the -fexceptions value in  
> the IR.

I don't see the point.  If you don't have -fexceptions then you don't
get any exception handling constructs generated in the IR in the place.
The costs of turning on -enable-eh for IR with no eh constructs are:
(1) frame info generated all over the place; (2) reduced branch folding
due to nounwind calls being bracketed by labels.  However (1) could
easily be improved - currently we generate frame info always if -enable-eh
is turned on, even if there is no need for it.  As for (2) I doubt it
costs much.  In short turning on -enable-eh seems rather harmless and could
be made even more harmless.

> People with C++ programs shouldn't need a BE flag to make a fundamental
> language feature work.
>
> > Don't all targets support sjlj?
>
> Apparently not, since there were a lot of new passes when I changed
> -enable-eh-correct to -enable-eh.  I haven't looked into the sjlj  
> implementation
> at all though, so I can't say why.

Well it doesn't handle things like... testing which exception it was!
(eh.selector and all that)  So it's not surprising some thing started
working.

Ciao,

Duncan.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: Whither exceptions

Duncan Sands-2
In reply to this post by Chris Lattner
> 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.
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev