[LLVMdev] Whither exceptions
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
> 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
> 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