-
Notifications
You must be signed in to change notification settings - Fork 150
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
SVector
type unstable for Julia v1.9 and --check-bounds=no
#1155
Comments
using Cthulhu with remarks, and effects on. Check-bounds=0
Check-bounds=auto
|
The failure comes from:
Check-bounds=0
Check-bounds=auto
|
cc: @aviatesk Noteworthy difference is:
|
From version 1.9 onwards, when `--check-bounds=no` is used, concrete-eval is completely disabled. However, it appears `--check-bounds=no` is still being used within the community, causing issues like the one reported in JuliaArrays/StaticArrays.jl#1155. Although we should move forward to a direction of eliminating the flag in the future (#48245), for the time being, there are many requests to carry out a certain level of compiler optimization, even when this flag is enabled. This commit aims to allow concrete-eval "safely" even under `--check-bounds=no`. Specifically, when the method call being analyzed is `:nothrow`, it should be predominantly safe to concrete-eval it under this flag. Technically, however, even `:nothrow` methods could trigger undefined behavior, since `:nothrow` isn't a strict constraint and it's possible for users to annotate potentially risky methods with `Base.@assume_effects :nothrow`. Nonetheless, since this possibility is acknowledged in `Base.@assume_effects` documentation, I feel it's fair to relegate it to user responsibility.
#50107) From version 1.9 onwards, when `--check-bounds=no` is used, concrete-eval is completely disabled. However, it appears `--check-bounds=no` is still being used within the community, causing issues like the one reported in JuliaArrays/StaticArrays.jl#1155. Although we should move forward to a direction of eliminating the flag in the future (#48245), for the time being, there are many requests to carry out a certain level of compiler optimization, even when this flag is enabled. This commit aims to allow concrete-eval "safely" even under `--check-bounds=no`. Specifically, when the method call being analyzed is `:nothrow`, it should be predominantly safe to concrete-eval it under this flag. Technically, however, even `:nothrow` methods could trigger undefined behavior, since `:nothrow` isn't a strict constraint and it's possible for users to annotate potentially risky methods with `Base.@assume_effects :nothrow`. Nonetheless, since this possibility is acknowledged in `Base.@assume_effects` documentation, I feel it's fair to relegate it to user responsibility.
This looks fixed, no? Probably thanks to JuliaLang/julia#50107 and JuliaArrays/StaticArraysCore.jl#28, this even works on v1.9: ▶ julia +1.9 --check-bounds=no -q
julia> using StaticArrays; @code_warntype SVector(1)
MethodInstance for (SVector)(::Int64)
from (::Type{SA})(x...) where SA<:StaticArray @ StaticArrays ~/.julia/packages/StaticArrays/lZeGV/src/convert.jl:173
Static Parameters
SA = SVector
Arguments
#self#::Type{SVector}
x::Tuple{Int64}
Body::SVector{1, Int64}
1 ─ nothing
│ %2 = $(Expr(:static_parameter, 1))::Core.Const(SVector)
│ %3 = StaticArrays.Args(x)::StaticArrays.Args{Tuple{Int64}}
│ %4 = StaticArrays.construct_type(%2, %3)::Core.Const(SVector{1, Int64})
│ %5 = (%4)(x)::SVector{1, Int64}
└── return %5
(@v1.9) pkg> st StaticArrays
Status `~/.julia/environments/v1.9/Project.toml`
[90137ffa] StaticArrays v1.9.11 ▶ julia +1.11 --check-bounds=no -q
julia> using StaticArrays; @code_warntype SVector(1)
MethodInstance for (SVector)(::Int64)
from (::Type{SA})(x...) where SA<:StaticArray @ StaticArrays ~/.julia/packages/StaticArrays/lZeGV/src/convert.jl:173
Static Parameters
SA = SVector
Arguments
#self#::Type{SVector}
x::Tuple{Int64}
Body::SVector{1, Int64}
1 ─ nothing
│ %2 = StaticArrays.construct_type::Core.Const(StaticArrays.construct_type)
│ %3 = $(Expr(:static_parameter, 1))::Core.Const(SVector)
│ %4 = StaticArrays.Args(x)::StaticArrays.Args{Tuple{Int64}}
│ %5 = (%2)(%3, %4)::Core.Const(SVector{1, Int64})
│ %6 = (%5)(x)::SVector{1, Int64}
└── return %6
(@v1.11) pkg> st StaticArrays
Status `~/.julia/environments/v1.11/Project.toml`
[90137ffa] StaticArrays v1.9.11 |
Yes, indeed, thanks for checking (I could also verify) 🥳 Unfortunately this doesn't solve all problems with using However, since I have not been able to isolate this sufficiently (yet), I will close the issue for now. Again, thanks for taking an interest (and also thanks to @aviatesk and @jipolanco for the upstream fixes 🙏) |
As described in JuliaLang/julia#49472, using StaticArrays.jl with Julia v1.9 and
--check-bounds=no
causes theSVector
constructor to be type unstable even for the simplest invocations.To reproduce, start Julia v1.9 (RC1 or later were tested and reproduce this problem) with
--check-bounds=no
and then run the following:Without
--check-bounds=no
, we get the expected, type stable output:This regression renders StaticArrays.jl virtually unusable with Julia v1.9 for many HPC workloads (hot kernels that make generous use of
SVector
basically grind to a halt). In the linked julia issue above it was hinted that this is not going to be fixed in Julia base, and @vchuravy suggested that I should rather file an issue here (keeping fingers crossed 🙏).cc @ranocha
The text was updated successfully, but these errors were encountered: