[LLVMdev] Whither exceptions

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


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.



More information about the llvm-dev mailing list