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

[Dale Johannesen]

On Apr 6, 2008, at 11:58 AM, Duncan Sands wrote:

> Hi Chris,
>
>>        -funwind-tables
>>            Similar to -fexceptions, except that it will just generate
>> any needed static data, but will
>>            not affect the generated code in any other way.  You will
>> normally not enable this option;
>>            instead, a language processor that needs this handling
>> would enable it on your behalf.
>>
>>>
>>> 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.