[llvm-commits] [patch] Change how we handle mandatory unwind tables

[Rafael Ávila de Espíndola]

On 11-05-24 3:52 AM, Renato Golin wrote:
> 2011/5/24 Rafael Ávila de Espíndola<rafael.espindola at gmail.com>:
>> New version is attached. I added a ehframe attribute. Clang sets it if
>> the ABI mandates ehframes for all functions. The logic for nounwind
>> remains the same.
>
> Hi Rafael,
>
> Let me see if I got them right...
>
> The attribute ehframes would be emitted on every such ABI function?
> That would generate the tables even if nounwind is present, right?

Yes. It is the way the FE uses to say "I really want a unwind table for 
this function".

> So, ehframes is a global setting (ie. either all or none have it) and
> nounwind is on a case-by-case. In this scenario, I can't see what's
> the value of a function with nounwind only...

It is not a global setting. Consider (on x86-64)

$ clang -c foo.c -emit-llvm
$ clang -c bar.c -emit-llvm -fno-asynchronous-unwind-tables
$ clang -use-gold-plugin foo.o bar.o -o zed

The functions from foo.c will have unwind tables, the ones from bar.c 
will not. This is the same result you would get without LTO.

> To put this into a table:
>
> nil = implementation defined?
> nounwind = ?
> ehframes = always generate
> ehframes + nounwuind = don't generate

No. It is:

nil                = Needs an eh frame because an exception might pass by.
nounwind           = No need for a eh frame
ehframe            = Needs an eh frame because the ABI says so and 
because an exception might pass by.
ehframe + nounwind = Needs an eh frame because the ABI says so.

Optimizations can add nounwind. This allows an invoke to become a call 
for example. If the FE added ehframe, we still get the eh table. If it 
did not, adding nounwind removes the only reason why we had an eh table 
and it is not generated.

> cheers,
> --renato

Cheers,
Rafael