vsk added a comment. In D56624#1369767 <https://reviews.llvm.org/D56624#1369767>, @yln wrote:
> In D56624#1369635 <https://reviews.llvm.org/D56624#1369635>, @vsk wrote: > > > What are the advantages of a generalized expect_noreturn attribute, vs. a > > narrower attribute or intrinsic? The expect_noreturn semantics do not > > provide strong guarantees, and are not really orthogonal from the > > pre-existing cold attribute. > > > @eugenis Do you want to chime in here? > I think they convey different meanings even if their treatment by the > optimizer is similar. The `cold` attribute says nothing about whether or not > a function is expected to return. That's my point: it doesn't need to, because it's orthogonal. It's just a hint that a call is cold and could be profitable to split/reorder. Features of llvm IR generally try to be orthogonal to reduce complexity in the optimizer. >> In particular, expect_noreturn doesn't even seem strong enough to allow ASan >> to unpoison its stack. > > I am not sure I understand this part. Can you elaborate? Because "expect_noreturn" calls are allowed to return, the compiler must behave as they could. In particular, this means that unpoisoning the stack before expect_noreturn calls (given the current semantics) is premature. Put another way, a frontend author may (understandably, but mistakenly!) attach expect_noreturn to calls which they expect to be cold. That would regress ASan coverage. Repository: rL LLVM CHANGES SINCE LAST ACTION https://reviews.llvm.org/D56624/new/ https://reviews.llvm.org/D56624 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
