-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
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
optimizer: ssaflags
validation after optimization ?
#42258
Comments
…ge statements It seems that this change still doesn't resolve #42258 though.
…ge statements It seems that this change still doesn't resolve #42258 though.
…ge statements It seems that this change still doesn't resolve #42258 though.
Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of #42260.
It sounds like our flags are incorrectly defined. Dropping statement flags is supposed to always be legal, so |
Hmm, I can't follow you. It turns out that this issue is caused by that |
Sometimes we'll insert or move statements, and (like LLVM) need to drop flags since we won't know if they are still applicable |
…ge statements It seems that this change still doesn't resolve #42258 though.
Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of #42260.
Okay, so we need to validate statement flags on two levels ?
I think #42260 and #42262 are necessary for 1., and we can consider about 2. later. |
Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of #42260.
Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of #42260.
Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of #42260.
ssaflags
can be strange after optimizationssaflags
validation after optimization ?
The first flag skew should be fixed and will be kept being asserted by #42262 . Probably the next step would be to find a concrete case where |
Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of #42260.
…ng coverage statements (JuliaLang#42260) It seems that this change still doesn't resolve JuliaLang#42258 though.
…JuliaLang#42262) Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of JuliaLang#42260.
…ng coverage statements (JuliaLang#42260) It seems that this change still doesn't resolve JuliaLang#42258 though.
…JuliaLang#42262) Essentially, this PR adds missing `ssaflags` deletion of `type_annotate!`. Built on top of JuliaLang#42260.
It seems that
(ci::CodeInfo).ssaflags
is sometimes processed badly during optimization(and it will confuse the inlining cost model).
Given the following definition of
Core.Compiler.setindex!(::Core.Compiler.UseRef, ::Any)
:julia/base/compiler/ssair/ir.jl
Lines 415 to 455 in 3794f9a
I found
ssaflags
is set correctly before optimization (every "throw block" gets marked withIR_FLAG_THROW_BLOCK = 0x01 << 3
:But after optimization some
0x08
statements no longer correspond to "throw block", and rather they're scattered around arbitrary places:There are several points where new statement can be inserted in the optimization, and AFAIU we basically need to check if each construction of
NewInstruction
is valid and correctly inherits the statement flags:julia/base/compiler/ssair/ir.jl
Lines 154 to 175 in 3794f9a
This issue might also confuse
propagate_inbounds
and callsite inlining stuff, because they also usessaflags
set before optimization.As a final target, the following case should pass once this issue gets resolved:
The text was updated successfully, but these errors were encountered: