[LLVMdev] exact semantics of 'nounwind'

[Duncan Sands]

Hi Nick,

> Since I'm busy muddying the waters by changing how exception handling 
> works, I thought I should ask for clarification on the exact behaviour 
> of the current 'nounwind' attribute found on functions, calls and invokes.
> 
> I was thinking these would be similar to the AA analysis notes like 
> "doesNotAccessMemory" which is a provable property of the function or 
> call site being analyzed. Duncan mentioned that doesNotThrow is actually 
> an important language semantic meaning that an unwind calls a 
> language-defined behaviour such as calling terminate(). What happens in 
> other languages?
> 
> Chris and I also couldn't agree on what the semantics ought to be going 
> forward. He suggested having two bits, one to memoize an analysis 
> proving that it can't unwind, and one to mean that an unwind triggers 
> terminate. I happen to think that this ought to be explicitly modelled 
> in the IR by arcing to another BB that calls terminate.
> 
> We do agree that we need crystal-clear semantics in the language, so I'm 
> taking it to the mailing list to see what if we can form a consensus.

the exotic part of nounwind semantics has now been removed (this was that
the nounwind attribute had to be carefully preserved and propagated down
to the codegenerators, which would put a special entry in the dwarf eh
tables, because C++ semantic correctness was depending on the runtime
being informed about nounwind calls), so now it can simply mean: this
has been proved not to throw.  And if it does throw, the effect is
undefined.

Ciao,

Duncan.