On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote:> Hi Bill, > >> This is a (very) rough patch to fix building LLVM with exceptions on >> PPC Darwin. Basically, it puts the burden of adding the "--enable-eh" >> on the specific target, which is where I think it should go. > > I don't like it. LLVM has plenty of features that are not supported > on all targets, why should it be the responsability of llvm-gcc to > manage > this particular one and not the others? It is true that llvm-gcc is > currently the only producer of eh intrinsics. But hopefully this will > not always be the case; must all front-ends to LLVM manage -enable-eh? > If LLVM doesn't support exception handling for a target then - > enable-eh > causes eh code to be lowered to nothing. It seems to me that > problem with > x86-darwin is that LLVM thinks eh is supported but it isn't. Why > not simply > set SupportsExceptionHandling to false for that target?I agree with Duncan: can't the target (which knows the capabilities of the currently selected subtarget) set the value of SupportsExceptionHandling correctly? -Chris
On Aug 28, 2007, at 11:35 PM, Chris Lattner wrote:> On Aug 28, 2007, at 11:20 PM, Duncan Sands wrote: > >>> This is a (very) rough patch to fix building LLVM with exceptions on >>> PPC Darwin. Basically, it puts the burden of adding the "--enable- >>> eh" >>> on the specific target, which is where I think it should go. >> >> I don't like it. LLVM has plenty of features that are not supported >> on all targets, why should it be the responsability of llvm-gcc to >> manage >> this particular one and not the others? It is true that llvm-gcc is >> currently the only producer of eh intrinsics. But hopefully this >> will >> not always be the case; must all front-ends to LLVM manage -enable- >> eh? >> If LLVM doesn't support exception handling for a target then - >> enable-eh >> causes eh code to be lowered to nothing. It seems to me that >> problem with >> x86-darwin is that LLVM thinks eh is supported but it isn't. Why >> not simply >> set SupportsExceptionHandling to false for that target? > > I agree with Duncan: can't the target (which knows the capabilities > of the currently selected subtarget) set the value of > SupportsExceptionHandling correctly? >They do. However, it doesn't seem to stop it from failing during compilation of unwind-dw2.c for libgcc -- it has "__builtin_eh_return" in it. During 4-way FAT PPC compilation, it tries to compile this file and fails during the LowerOperation function. Turning --enable-eh off makes the error go away. It may be my lack of understanding, but it appears that having -- enable-eh set during compilation of llvm-gcc is causing extra files to be compiled. During bootstrapping, these files seem to rely upon having the EH stuff in place. That's why it's "special" w.r.t. the other features that aren't supported on all platforms. Yes, it's ugly, and I don't like it either. I'm open to suggestions on what could be the cause of the failure I'm seeing with unwind- dw2.c, et al, other than EH support. -bw
Hi Bill,> > I agree with Duncan: can't the target (which knows the capabilities > > of the currently selected subtarget) set the value of > > SupportsExceptionHandling correctly? > > > They do.indeed SupportsExceptionHandling is set to false for all 64 bit targets (that said, someone should test 32 bit x86-darwin).> However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During 4-way FAT PPC compilation, it > tries to compile this file and fails during the LowerOperation > function. Turning --enable-eh off makes the error go away.In LegalizeDAG, EH_RETURN should be lowered to nothing on a 64 bit target, see the logic in the "Legal" case. So it seems like the "lower to nothing" logic is not working properly.> It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled.No, it only effects LLVM codegen.> During bootstrapping, these files seem to rely upon > having the EH stuff in place. That's why it's "special" w.r.t. the > other features that aren't supported on all platforms.No, when -enable-eh is turned off the LLVM eh_return intrinsic is still generated. However it is lowered to nothing at the level of SelectionDAGISel. If -enable-eh is turned on then a selection DAG node is created for it, which is lowered to nothing at the level of LegalizeDAG. There is clearly a bug in this last part.> Yes, it's ugly, and I don't like it either. I'm open to suggestions > on what could be the cause of the failure I'm seeing with unwind- > dw2.c, et al, other than EH support.Please compile unwind-dw2.c to bytecode and send it in. That way I will be able to reproduce the problem. Ciao, Duncan.