[llvm-commits] add nounwind flag to BasicBlock

[Nick Lewycky]

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