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

[Renato Golin]

2011/5/24 Rafael Ávila de Espíndola <rafael.espindola at gmail.com>:
> 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.

I see. This is like genetics, you have the dominant and the recessive
gene. In this case, 'ehframe' is the dominant, 'nounwind' is the
contra-recessive.

Now I see where you were coming from your proposal to put that into
the TargetData, because the behaviour is module-wide and in TargetData
would forbid optimizations to add the 'nounwind'.

So, while the TargetData change makes more sense, it brings deeper
changes. But adding the ehframe to functions will create confusion (as
seen in this thread), and having hidden rules for ABIs is a no go (as
seen in the exception handling thread in the dev-list).

I personally don't mind the 'ehframe' as long as it's documented
extensively (with the options you just put in the email).

cheers,
--renato