PkgEval detected issues or regressions? #39641
Comments
vtjnash
added
the
regression
|
The OptionalArgChecks one can be safely ignored, since it manipulates IR in some really bad and wrong ways. I just couldn't be bother to fix it yet. (Is there a good way to exempt a package from PkgEval? Or perhaps I will just add a check in the test suite that checks the version and just quits if it is too new.) |
|
Yes, the package should be upper bounded on version compatibility |
|
Off topic, but related: Should PkgEval daily evaluations always compare against the latest release? That way new failures wouldn't disappear after a single run. |
I think that would be useful. |
|
Any package that fails on a release build should be removed from General for that release, so that ability to see that comparison should already be present. Perhaps we could even add an Unstable channel, where package versions automatically get moved if they fail PkgEval too much, or don't have sufficient test coverage? |
What do you mean "removed from General for that release"? If you are meaning that the version of the package should no longer be installable on that Julia release because PkgEval marked that it has a test failure, that is just completely out of the question. |
|
I've narrowed down ProximalAlgorithms to being an issue with the llvm-alloc-opt.cpp pass (@yuyichao, if interested), with some details added above. |
LLVM will switch to this form, so it is preferable to start that way. Refs Matcha in #39641
At runtime, it is prohibited to observe these values, but we need to make sure they are not reading through undefined pointers (and potentially trying to GC-root the memory there) Refs ChainRules in #39641
LLVM will switch to this form, so it is preferable to start that way. Refs Matcha in #39641
At runtime, it is prohibited to observe these values, but we need to make sure they are not reading through undefined pointers (and potentially trying to GC-root the memory there) Refs ChainRules in #39641
LLVM will switch to this form, so it is preferable to start that way. Refs Matcha in JuliaLang#39641
At runtime, it is prohibited to observe these values, but we need to make sure they are not reading through undefined pointers (and potentially trying to GC-root the memory there) Refs ChainRules in JuliaLang#39641
LLVM will switch to this form, so it is preferable to start that way. Refs Matcha in JuliaLang#39641
At runtime, it is prohibited to observe these values, but we need to make sure they are not reading through undefined pointers (and potentially trying to GC-root the memory there) Refs ChainRules in JuliaLang#39641
Looking through recent PkgEval run for segfaults, these seem worth investigating:
Fails due to:
Which is #35130 (comment)
This is similar to ProximalAlgorithms, though in this case, it is a hoisted FCA load of a getfield:
This is specifying
[compat]for an antiquated version of https://github.com/JuliaOpt/NLopt.jl which was broken.This appears to be a bug in PhiNode handling in llvm-alloc-opt.cpp. In particular, we have this node:
which turns into:
and
after (splitting on isa). This ends up confusing
llvm-alloc-opt.cpp, which tries to fold the PhiNode and then marks that first slot as containing a ref. This violates LLVM's typed-memory assumption that all loads through a particular pointer must share the same type. This pass either needs to further split the users (into ref and value slots) or inhibit the optimization when the types collide like this.To see this in usage, try:
code_llvm(ProximalAlgorithms.iterate, (ProximalAlgorithms.DRLS_iterable{Float64, Float64, Vector{Float64}, ProximalAlgorithms.ProximalOperators.LeastSquaresDirect{1, Float64, Float64, Matrix{Float64}, Vector{Float64}, Cholesky{Float64, Matrix{Float64}}}, NormL1{Float64}, ProximalAlgorithms.LBFGS{Float64, Float64, Int64, Vector{Float64}, 5}}, ProximalAlgorithms.DRLS_state{Float64, Vector{Float64}, ProximalAlgorithms.LBFGS{Float64, Float64, Int64, Vector{Float64}, 5}}))LLVM is normalizing our
return_rootsalloca fromT, nto[T x n], which involves adding aGEP 0,0before the user. Somehow this GEP gets sunk into a loop, and ends up generating a bunch of phi nodes, which all are the same GEP into the same original alloca.From:
code_llvm(Matcha.inner_matchat, (Vector{Int64}, Int64, Tuple{Greed{typeof(Matcha.alwaysmatch), UnitRange{Int64}}, Greed{Int64, UnitRange{Int64}}}, Matcha.History{Vector{Int64}, SubArray, Int64}))The text was updated successfully, but these errors were encountered: