-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
effects: allow override of :nonoverlayed
effect bit (and rename it to :native_executable
)
#51080
Conversation
Would it be more accurate to call this "host compiler & runtime"? It's possible to have a native runtime for the target architecture that's different from the runtime where the compilation happens. |
I'm not sure the semantics of this effect override are precisely enough defined. I think we need to be very clear and careful what this is promising here. For the purposes of allowing constprop, I think all we need is that the overlay is consistent (in the |
ad24c70
to
00b5060
Compare
ec29009
to
fe13b92
Compare
Certain external `AbstractInterpreters`, such as GPUCompiler.jl, have long sought the ability to allow concrete evaluation for specific overlay-ed methods to achieve optimal inference accuracy. This is currently not permitted, although it should be safe when an overlay-ed method has the same semantics as the original method, and its result can be safely replaced with the result of the original method. Refer to JuliaGPU/GPUCompiler.jl#384 for more examples. To address this issue, this commit introduces the capability to override the `:nonoverlayed` effect bit using `@assume_effects`. With the enhancements in PR #51078, this override behaves similarly to other effect bits. Consequently, external `AbstractInterpreters` can utilize this feature to permit concrete evaluation for annotated overlay-ed methods, e.g. ```julia @overlay OVERLAY_MT Base.@assume_effects :nonoverlayed f(x) = [...] ``` However, it now seems awkward to annotate a method with `Base.@assume_effects :nonoverlayed` when it is actually marked with `@overlay`. A more intuitive terminology, like `native_executable`, might be more appropriate for renaming the `:nonoverlayed` effect bit.
fe13b92
to
b0eaabc
Compare
This PR has gotten quite stale, so I'm going to close it for now. I'll have a new one ready soon, and we can pick up the discussion on that one. |
This PR serves to replace #51080 and close #52940. It extends the `:nonoverlayed` to `UInt8` and introduces the `CONSISTENT_OVERLAY` effect bit, allowing for concrete evaluation of overlay methods using the original non-overlayed counterparts when applied. This newly added `:nonoverlayed`-bit is enabled through the newly added `Base.Experimental.@consistent_overlay mt def` macro. `@consistent_overlay` is similar to `@overlay`, but it sets the `:nonoverlayed`-bit to `CONSISTENT_OVERLAY` for the target method definition, allowing the method to be concrete-evaluated. To use this feature safely, I have also added quite precise documentation to `@consistent_overlay`.
This PR serves to replace #51080 and close #52940. It extends the `:nonoverlayed` to `UInt8` and introduces the `CONSISTENT_OVERLAY` effect bit, allowing for concrete evaluation of overlay methods using the original non-overlayed counterparts when applied. This newly added `:nonoverlayed`-bit is enabled through the newly added `Base.Experimental.@consistent_overlay mt def` macro. `@consistent_overlay` is similar to `@overlay`, but it sets the `:nonoverlayed`-bit to `CONSISTENT_OVERLAY` for the target method definition, allowing the method to be concrete-evaluated. To use this feature safely, I have also added quite precise documentation to `@consistent_overlay`.
This PR serves to replace #51080 and close #52940. It extends the `:nonoverlayed` to `UInt8` and introduces the `CONSISTENT_OVERLAY` effect bit, allowing for concrete evaluation of overlay methods using the original non-overlayed counterparts when applied. This newly added `:nonoverlayed`-bit is enabled through the newly added `Base.Experimental.@consistent_overlay mt def` macro. `@consistent_overlay` is similar to `@overlay`, but it sets the `:nonoverlayed`-bit to `CONSISTENT_OVERLAY` for the target method definition, allowing the method to be concrete-evaluated. To use this feature safely, I have also added quite precise documentation to `@consistent_overlay`.
This PR serves to replace #51080 and close #52940. It extends the `:nonoverlayed` to `UInt8` and introduces the `CONSISTENT_OVERLAY` effect bit, allowing for concrete evaluation of overlay methods using the original non-overlayed counterparts when applied. This newly added `:nonoverlayed`-bit is enabled through the newly added `Base.Experimental.@consistent_overlay mt def` macro. `@consistent_overlay` is similar to `@overlay`, but it sets the `:nonoverlayed`-bit to `CONSISTENT_OVERLAY` for the target method definition, allowing the method to be concrete-evaluated. To use this feature safely, I have also added quite precise documentation to `@consistent_overlay`.
Certain external
AbstractInterpreters
, such as GPUCompiler.jl, havelong sought the ability to allow concrete evaluation for specific
overlay-ed methods to achieve optimal inference accuracy. This is
currently not permitted, although it should be safe when an overlay-ed
method has the same semantics as the original method, and its result can
be safely replaced with the result of the original method. Refer to
JuliaGPU/GPUCompiler.jl#384 for more examples.
To address this issue, this commit introduces the capability to override
the
:nonoverlayed
effect bit using@assume_effects
. With theenhancements in PR #51078, this override behaves similarly to other
effect bits.
However, it now seems awkward to annotate a method with
Base.@assume_effects :nonoverlayed
when it is actually marked with
@overlay
. Thus the second commitreplaces
:nonoverlayed
with (hopefully) more appropriate terminology,:native_executable
. This terminology is intended to indicate that themethod is concrete-evaluable. More specifically, it means that
(quoting from the new
Base.@assume_effects
docstring):Consequently, external
AbstractInterpreters
can utilizethis feature to permit concrete evaluation for annotated overlay-ed
methods, e.g.