Removal of `@pure` makes constant-prop less effective.

[sloede]

With the current commit on the backports-release-1.9 branch (29889c7), in StaticArrays.jl a type instability is triggered when running Julia with --check-bounds=no. I tried to create an MWE as follows:

Start Julia with

JULIA_DEPOT_PATH=$PWD/tmp-depot path/to/julia-1.9-29889c7a1c --project=. --check-bounds=no

for a clean depot. Then run the following code:

julia> using Pkg; Pkg.add(PackageSpec(name="StaticArrays", version=v"1.5.21"))

julia> using StaticArrays

julia> some_vec = SVector(1.0)
1-element SVector{1, Float64} with indices SOneTo(1):
 1.0

julia> foo(u) = SVector(u[1])
foo (generic function with 1 method)

julia> @code_warntype foo(some_vec)
MethodInstance for foo(::SVector{1, Float64})
  from foo(u) @ Main REPL[4]:1
Arguments
  #self#::Core.Const(foo)
  u::SVector{1, Float64}
Body::Any
1 ─ %1 = Base.getindex(u, 1)::Float64
│   %2 = Main.SVector(%1)::Any
└──      return %2

When starting Julia without --check-bounds=no, the output of @code_warntype is as expected:

julia> @code_warntype foo(some_vec)
MethodInstance for foo(::SVector{1, Float64})
  from foo(u) @ Main REPL[4]:1
Arguments
  #self#::Core.Const(foo)
  u::SVector{1, Float64}
Body::SVector{1, Float64}
1 ─ %1 = Base.getindex(u, 1)::Float64
│   %2 = Main.SVector(%1)::SVector{1, Float64}
└──      return %2

This causes a considerable performance regression to the point that code that heavily uses StaticArrays in hot loops becomes unusable.

cc @ranocha

[sloede]

Note that this behavior for --check-bounds=no can already be observed for Julia v1.9.0-RC1 (but wasn't noticed by me until now).

[vtjnash]

Yes, this is expected. Do not use check-bounds=no if you want fast code, as it introduces undefined behavior into the code and forces Julia to emit worse code to compensate for that problem. For reference, see: #48245

[sloede]

I am aware of that discussion. However, if I understand it correctly, the conclusion was to not yet disallow --check-bounds=no until a way forward was found that does not break existing workflows (cc @vchuravy). However, if not even StaticArrays is going to work anymore, this effectively kills it for everyone needing to work with non-allocating arrays, i.e., a large chunk of the people and packages in the HPC world.

Are you saying that this issue is wontfix, and that with Julia v1.9, --check-bounds=no is no longer a viable option?

cc @omlins @luraess

[vchuravy]

Note my observation in JuliaArrays/StaticArrays.jl#1155 (comment)

[vchuravy]

We have at least two execution environments that heavily rely on constant-propagation and can't use concrete-evaluation.

1. GPU code uses a custom method table, with functions that are not concrete-evaluable on the Host.
2. --check-bounds=no (for all it's faults) disables concrete-evaluation

The removal of @pure makes this worse since it prohibits work-arounds like JuliaArrays/StaticArrays.jl#1156

@aviatesk is constant propagation using the effect system? Trying @sloede test-case on JuliaArrays/StaticArrays.jl#1156 shows that Julia 1.10 will regress the situation again.

[aviatesk]

• GPU code uses a custom method table, with functions that are not concrete-evaluable on the Host.

To increase the chances of concrete evaluation for an external compiler pipeline using a custom method table, we can separate :nonoverlayed into :nonoverlayed and :may_be_overlayed_but_still_eligible_for_concrete_eval. This allows us to concretely evaluate methods with expected overlayed behavior at runtime. For example:
E.g.

# this overlay isn't really concrete-eval-eligible
@overlay sin(x::Union{Float32,Float64}) = cos(x)

# this overlay might be concrete-eval-eligible, assuming that we are okay with having this error on CPU env during compile time
@overlay throw_some_error(x) = throw_on_gpu_env(x)

• --check-bounds=no (for all it's faults) disables concrete-evaluation

We can also boost the chances of concrete evaluation for processes using --check-bounds=no by separately tracking :consistent and :consistent_regardless_of_boundschecking. However, after looking into #48245, my conclusion is that we should remove the flag since it only allows incorrect optimization while blocking correct optimizations, making any extra effort to optimize it unnecessary.