vsk added a comment. In D56624#1370243 <https://reviews.llvm.org/D56624#1370243>, @eugenis wrote:
> > 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. > > I don't think that's true. A hypothetical function > > maybe_longjmp(jmp_buf env) > > that checks an opaque condition needs stack unpoisoning before the call, in > the absense of a better solution. Wouldn’t it be preferable to unpoison the stack inside of maybe_longjmp, once the opaque condition can be checked? Even if not, a narrower sanitizer_noreturn attribute is still perfectly fine, here. > One possible optimization that I can think of is splitting code after the > call into a separate basic block and marking it as cold. > Admittedly, that's unlikely to have big impact in practice. I'd guess that > [[expect_noreturn]] calls are typically not very hot in the first place. The cold attribute is already used for this kind of splitting/reordering. I don't yet see how expect_noreturn creates new opportunities for the optimizer. 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
