Woah, I didn’t know that was the reason for you folks asking for a way to disable __builtin_assume. As an extremely optimizer-naive user, I find this completely nuts (even though I know there are really good reasons for it). On the libc++ side, we were naively using __builtin_assume with the intent of giving more semantic information to the optimizer so it can do its job better. Seeing that’s usually not the case, I am tempted to simply remove __builtin_assume from libc++'s assertions until the compiler has been fixed/improved, if we think there’s a way we can get there.
Otherwise, if we don’t think we’ll get to a point where we can throw __builtin_assume around without preventing optimizations, I think we need to clearly document the cases where it makes sense to use the attribute and try to rely on a good shared understanding of how the attribute operates in the community. Barring that, I believe people are going to use it the exact same naive way libc++ has been using it and they will get the inverse of what they wanted, which would make this feature essentially a giant footgun.
I think that captures nicely what we haven’t been doing (in libc++). However, as a decent representative for optimizer-naive users, I think that requiring assumptions to have an intent makes them close to useless for the average programmer. You have to already know how the optimizer thinks in order to do that properly, and the average user just doesn’t.
I’m sure this is harder to fix than I can imagine. In the short term, I think we should probably do @jdoerfert 's step (0) and drop assumptions much more liberally. And in the even shorter term, I’m going to disable __builtin_assume from libc++'s assertions so we at least don’t ship LLVM 17 with an obvious case of “non-intentional assumptions” until we have more clarity.
Edit: The libc++ patch is ⚙ D153968 [libc++] Stop using __builtin_assume in _LIBCPP_ASSERT