I was referring to llvm assume. It’s equivalent to skipping the throw in codegen, and just emitting unreachable for the out-of-bounds branch in codegen for Core.arrayset / Core.arrayref.
It basically tells the compiler to assume that the array access is in-bounds, on pain of undefined behavior.
Note from my above example that this is a much stronger “inbounds” promise than mere “don’t bother to check bounds”. E.g. people who decide to read beyond the array bounds and use masks to ignore the garbage for SIMD would be hosed by that interpretation (just as they would be in C). But these people are somewhat hosed anyways – they might get a segfault if the array ends at a page boundary. And people who bother to check for page boundaries when overreading should probably use the Core.pointerref-based API anyways.
When did I ever encourage anyone to use @inbounds? I feel that each particular use of @inbounds should be justified. @inbounds should only be considered when it’s clear that:
it significantly improves performance (when using a given Julia release)
the performance of the relevant code matters
Given the above, I’ve felt for some time already that @inbounds is often carelessly misused in the Julia ecosystem. This is, however, no excuse to cripple @inbounds.
I haven’t said you do, I didn’t mean to imply that. It’s just relatively prevalent in the community, is all.
Noone is talking about “crippling @inbounds”; and certainly not to discourage people from using it, if appropriate. From the POV of the compiler, @inbounds is just very hard to optimize with, that’s all.
Sorry to dig this up, but on a related note: is there a way to maintain constant propagation when using an index type that, by construction, guarantees inbounds access? (Or, for that matter, indexing a type which guarantees this property?)