# Why does \`@inbounds\` disable constant propagation?

**URL:** https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789
**Category:** Internals & Design
**Tags:** constant-propagation, inbounds
**Created:** [November 4, 2023, 9:15am UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789 "2023-11-04T09:15:10Z")
**Posts on this page:** 6
**Page:** 2

<div class="post-metadata">

### Author: ![foobar\_lv2](https://avatars.discourse-cdn.com/v4/letter/f/ee59a6/32.png) [@foobar\_lv2](https://discourse.julialang.org/u/foobar_lv2)
#### Post date: [November 7, 2023, 9:27am UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789/21 "2023-11-07T09:27:09Z")

</div>

> [@Sukera](#):
>
> Julia doesn’t have such an `assume`, if I’m intuiting the meaning correctly here.

I was referring to [llvm assume](https://llvm.org/docs/LangRef.html#llvm-assume-intrinsic). It’s equivalent to skipping the `throw` in codegen, and just emitting [unreachable](https://llvm.org/docs/LangRef.html#unreachable-instruction) 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.

---

<div class="post-metadata">

### Author: ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [November 8, 2023, 9:56am UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789/22 "2023-11-08T09:56:42Z")

</div>

> [@Sukera](#):
>
> That’s exactly why people should not be encouraged to use it when they don’t know why their code is slow.

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:

1. it _significantly_ improves performance (when using a given Julia release)
2. 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`.

---

<div class="post-metadata">

### Author: ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)
#### Post date: [November 8, 2023, 12:41pm UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789/23 "2023-11-08T12:41:29Z")

</div>

> [@nsajko](#):
>
> When did I ever encourage anyone to use `@inbounds`?

I haven’t said you do, I didn’t mean to imply that. It’s just relatively prevalent in the community, is all.

> [@nsajko](#):
>
> This is, however, no excuse to cripple `@inbounds`.

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.

---

<div class="post-metadata">

### Author: ![brainandforce](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/brainandforce/32/211054_2.png) [@brainandforce](https://discourse.julialang.org/u/brainandforce)
#### Post date: [March 12, 2024, 4:43am UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789/24 "2024-03-12T04:43:18Z")

</div>

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?)

---

<div class="post-metadata">

### Author: ![nsajko](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/nsajko/32/221187_2.png) [@nsajko](https://discourse.julialang.org/u/nsajko)
#### Post date: [January 19, 2025, 11:26pm UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789/25 "2025-01-19T23:26:20Z")

</div>

> [@nsajko](#):
>
> The Julia manual [says](https://docs.julialang.org/en/v1.11-dev/base/base/#Base.@assume_effects):
> 
> > An explicit `@inbounds` annotation inside the function will also disable constant folding and not be overridden by `:foldable`.

Up until now I think I interpreted this sentence in the doc string as saying that `@inbounds` disables constant folding in a way that can’t be overriden with `@assume_effects :foldable`. Then why does this constant fold on all Julia versions supporting `@assume_effects`:

```julia
Base.@assume_effects :foldable function f(a::Tuple{Vararg{Int}})
    r = 3
    for i ∈ eachindex(a)
        r += @inbounds a[i]
    end
    r
end

g() = f((10, 20, 30, 40, 50))
code_typed(g, Tuple{})

```

---

<div class="post-metadata">

### Author: ![Oscar\_Smith](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/oscar_smith/32/25343_2.png) [@Oscar\_Smith](https://discourse.julialang.org/u/Oscar_Smith)
#### Post date: [January 20, 2025, 12:00am UTC](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789/26 "2025-01-20T00:00:58Z")

</div>

I think those docs are just wrong.

[Previous page](https://discourse.julialang.org/t/why-does-inbounds-disable-constant-propagation/105789.md?page=1)
