[llvm-commits] [llvm-gcc-4.2] r49253 - /llvm-gcc-4.2/trunk/gcc/llvm-backend.cpp

[Duncan Sands]

Hi,

> On MacOS there are various parts of the system that need to be able to  
> do stack trackbacks at runtime.  On x86-32 this is done by  
> disassembling the code; for this to work -fenable-fp-elim must be  
> turned off.  There is a significant performance hit for that, so  
> x86-64 does it by looking at Dwarf unwind info.  For this to work  
> unwind info must be present for all functions.  This consideration is  
> independent of exceptions.
>
> The way this is done is that -funwind-tables is implicitly passed to  
> all compilations on Darwin x86-64.  This has the effect of generating  
> the Dwarf traceback tables (what you call frame moves, I believe) in  
> all cases.  (gcc does not even generate the ".eh=0" elision in leaf  
> functions; I think this is a bug in llvm-gcc, although so far it  
> hasn't broken anything.)  For languages that normally use exceptions, C 
> ++ and Obj-C++, -fexceptions is also passed, which additionally  
> generates landing pad info.
> 
> Now we can argue about what -funwind-tables and -fexceptions ought to  
> mean, it is certainly not clear in the documentation, but I think what  
> shipping gcc does with them is a good place to start.  If these  
> switches behave differently in another environment I suppose we need  
> to make their behavior dependent on the environment; I have no  
> knowledge of that right now.  In what follows I am going to use the  
> Darwin x86-64 meanings of these flags.
> 
> -fexceptions does not imply -funwind-tables, although they generate  
> some of the same info.  The difference is that info produced by virtue  
> of -funwind-tables cannot be removed; the OS needs it.  It would be OK  
> for prune-eh to remove landing pad info.  If -fexceptions is present  
> and -funwind-tables is not, it is OK to remove both.  I believe the  
> current behavior matches this.

I think we all agree about what the final effect of -funwind-tables should
be.  For me the only question is whether -funwind-tables should be represented
in the IR or not, and if so how.  My preference goes to an llc option.  This
has the disadvantage that you can't control the -funwind-tables effect on a
per-function basis, but based on the Darwin use case you describe that isn't
needed anyway (nor for Ada).

> Now, how do we reconcile this with what Ada does, and what info do we  
> put in the IR to make it happen?

Ada is getting -funwind-tables because it uses -fnon-call-exceptions (which
we don't currently support).  I actually don't see why -fnon-call-exceptions
would need -funwind-tables; it will I guess become clear one way or another
when support is added for -fnon-call-exceptions.  However Ada also has a stack
traceback facility which uses the dwarf unwinder, and for that to work it
presumably needs -funwind-tables.  In short: Ada doesn't seem to need anything
particularly special here, it's basically the same as Darwin.

Ciao,

Duncan.