[LLVMdev] exact semantics of 'nounwind'

Duncan Sands
2008-03-15T12:41:27Z

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.