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