[clang] [clang] add array out-of-bounds access constraints using llvm.assume (PR #159046)

Aaron Ballman via cfe-commits cfe-commits at lists.llvm.org
Tue Oct 7 05:31:24 PDT 2025


AaronBallman wrote:

> I would be carful exploiting this kind of information, possibly protect is with a compiler switch in the tradition of `-fstrict-aliasing`.

+1 to this.

> It probably makes sense to start off with this under a flag -fassume-array-bounds that is off by default, and it looks like an interesting option on itself that people may want to play with, but for our use-case we would like to have this on by default at some point. So, my high-level question is: what do we think the chance is to get this enabled by default?

I think the answer to that requires more data. How much of a performance benefit do these assumptions get the user under a wide varieties of workloads? When trying the changes on a wide corpus of test cases, how many silent behavioral changes do the assumptions cause? Are tools still able to help folks catch the bugs with their code or do we need to invest in tooling more before we should enable this option by default?

My misgivings here boil down to the usual tension between eeking out as much performance as possible and avoiding catastrophic security concerns. Personally, I don't know that I'd want to see this option on by default unless the benefits were quite significant; I think the ecosystem is strongly leaning towards making things more secure by default. I generally think something like -fbounds-safety makes more sense as a default and require people to opt out of it if they want to eek more performance out.

https://github.com/llvm/llvm-project/pull/159046


More information about the cfe-commits mailing list