[LLVMdev] exact semantics of 'nounwind'
baldrick at free.fr
Sat Mar 15 05:41:27 PDT 2008
> 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
More information about the llvm-dev