effects: allow override of :nonoverlayed effect bit (and rename it to :native_executable)#51080
effects: allow override of :nonoverlayed effect bit (and rename it to :native_executable)#51080
:nonoverlayed effect bit (and rename it to :native_executable)#51080Conversation
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
:nonoverlayedeffect 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 :nonoverlayedwhen it is actually marked with
@overlay. Thus the second commitreplaces
:nonoverlayedwith (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_effectsdocstring):Consequently, external
AbstractInterpreterscan utilizethis feature to permit concrete evaluation for annotated overlay-ed
methods, e.g.