[llvm] [IndVarSimplify] Allow predicateLoopExit on some loops with local writes (PR #155901)
Philip Reames via llvm-commits
llvm-commits at lists.llvm.org
Fri Aug 29 10:48:06 PDT 2025
preames wrote:
This is a really interesting idea. The basic approach can be phrased as allowing a trap to be taken early without all side effects in program order before the trap becoming visible. You restrict this to side effects for which another thread relying on them would already be UB.
I think this is probably technically sound, but I suspect uses might find it exceedingly surprising. The result of this optimization is that you have a failure which "looks like" you wrote out of bounds, but prior writes are not visible in a corefile, etc..
I can see where this would be very useful for a on-in-prouction variant of a C/C++ bounds checking system where the traps are fatal, non-recoverable, and critically non-inspectible. I don't know enough about e.g. asan, is this a clearly documented part of (any of) the usage models?
If so, I suspect we're going to have to find a way to describe the semantics split between the trap modes. Do we have an attribute today which means "program terminates, no recovery"? "noreturn" is somewhat close, but doesn't contain the bit about the entire heap becoming effectively dead. Though maybe in combination with inaccessiblememonly, it does?
Hm, the more I'm thinking about this, this seems like it can be phrased as simple an extremely aggressive form of dead store elimination.
https://github.com/llvm/llvm-project/pull/155901
More information about the llvm-commits
mailing list