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

[Dale Johannesen]

On Apr 6, 2008, at 1:01 PM, Dale Johannesen wrote:
>>>>
>>>> Out of curiosity, what kind of "something else" might this be?
>>>
>>> Some people want "unwind info no matter what".  For example, some
>>> performance tools want to be able to walk the stack etc with unwind
>>> info.  I don't think our current nounwind bit is sufficient to model
>>> this though, and I don't thank that overloading it to do so is a  
>>> good
>>> thing.
>
>> it sounds like -funwind-tables has no semantic effect so how about
>> making it an llc parameter?
>>
>> Another possibility is to output some debug intrinsic into functions.
>
> Where I am coming from here is that -fexceptions and -funwind-tables  
> are mutually exclusive, which is true for the environments we care  
> about (although as usual the documentation is mightily confusing).  - 
> funwind-tables will thus mark all calls nounwind, and all  
> definitions not-nounwind; I do think the current nounwind bit is  
> adequate to do this.  Pruning EH would not find any landing pads,  
> and should not remove the unwinding info ("frame moves"), so we  
> shouldn't run it.
>
> If my belief is not true in some other circumstances, e.g. Ada, that  
> would not work.  This is the right behavior for Darwin x86-64, at  
> least I think so; I could certainly make it contigent on that if  
> it's breaking Ada.

I didn't describe this right; "mutually exclusive" is not correct.   
Let me go at this another way, describing the gcc behavior that we  
need to imitate and the switches that gcc uses to achieve it.

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.

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