[LLVMdev] Whither exceptions

Duncan Sands duncan.sands at math.u-psud.fr
Thu Dec 20 13:08:04 PST 2007


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



More information about the llvm-dev mailing list