[LLVMdev] RFC: Patch for Exceptions

[Duncan Sands]

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.