[llvm-commits] add nounwind flag to BasicBlock
Nick Lewycky
nicholas at mxc.ca
Wed Mar 12 19:52:10 PDT 2008
Duncan Sands wrote:
> Hi Nick,
>
>> Like the nounwind flag on call and functions, this flag can be computed
>> by looking at the instructions inside the block,
>
> this seems wrong. The nounwind flag on a call can reflect front-end semantics:
> in C++ a call may not be allowed to unwind, for example a call that occurs
> as part of running a destructor during unwinding of an exception. Such a
> call is marked nounwind but this does not mean that the called function is
> a nounwind function, and in fact the callee may unwind. What it means is:
> (1) the optimizers may assume that the callee does not in fact unwind;
> (2) the runtime is informed (via entries in the dwarf eh tables) that the
> call is nounwind: if the runtime unwinder unwinds to such a call then it
> takes language specific action, which in the C++ case means calling terminate.
> Point (2) means that the nounwind flag needs to be carefully preserved (for
> example, propagated during inlining).
Ah! I didn't realize that nounwind on a CallInst actually meant that it
must call terminate in c++, I thought it was just "undefined behaviour
happens here".
I think it's the same as the nounwind flag on Functions though, no? They
don't have the same problem that the CallInst does?
> On the other hand, presumably instructions will themselves get a
> "nounwind" flag in which case the block flag can indeed be a summary
> of the instructions' flags.
>
> The patch itself looks ok to me.
>
> + /// setDoesNotThrow - Set whether unwinding is permissible in this
> + /// BasicBlock. Setting it to true will also clear the unwind dest.
>
> It sounds like this changes the cfg - is that the case (if so it seems
> unwise)?
You're right, this is very dangerous (what if there are PHI nodes that
need updating)? I will turn that into an assert.
Nick
More information about the llvm-commits
mailing list