Skip to content
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: some improvements for type-based-effects-analysis #46329

Open
wants to merge 1,418 commits into
base: avi/typetypeinf
Choose a base branch
from

Conversation

aviatesk
Copy link
Member

@aviatesk aviatesk added don't squash Don't squash merge compiler:effects effect analysis labels Aug 12, 2022
@aviatesk aviatesk force-pushed the avi/moreeffects branch 2 times, most recently from 182729a to 1c87730 Compare August 13, 2022 03:06
@aviatesk aviatesk force-pushed the avi/typetypeinf branch 2 times, most recently from 7e48407 to 6683109 Compare September 12, 2022 09:37
@@ -983,6 +983,9 @@ function getfield_notundefined(@nospecialize(typ0), @nospecialize(name))
# tuples and named tuples can't be instantiated with undefined fields,
# so we don't need to be conservative here
return true
elseif isType(typ) || typ === DataType
# types have never undefined fields
return true
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They have .singleton

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(the rest of the commits look good)

udohjeremiah and others added 22 commits March 2, 2023 23:11
…y` (#48854)

Previously the `:inaccessiblememonly` effect bit may be wrongly refined
when analyzing va-method, e.g.:
```julia
julia> callgetfield1(xs...) = getfield(getfield(xs, 1), 1)
callgetfield1 (generic function with 1 method)

julia> Base.infer_effects(callgetfield1, (Base.RefValue{Symbol},))
(+c,+e,!n,+t,+s,+m,+i) # inaccessiblememonly is wrongly refined here
```

This leads to wrong concrete evaluation of `callgetfield1` and thus may
result in a problem like below:
```julia
julia> const GLOBAL_XS = Ref(:julia);

julia> global_getfield() = callgetfield1(GLOBAL_XS);

julia> @test let
           Base.Experimental.@force_compile
           global_getfield()
       end === :julia
Test Passed

julia> GLOBAL_XS[] = :julia2;

julia> @test let
           Base.Experimental.@force_compile
           global_getfield()
       end === :julia2 # this fails
Test Failed at REPL[8]:1
  Expression: let
        #= REPL[8]:2 =# Base.Experimental.@force_compile
        global_getfield()
    end === :julia2
   Evaluated: julia === julia2
```

This commit fixes it up.
* Fix heapsize hint and use a line
so that large machines utilize more of their ram
According to the Juno website, development focus has been shifted to VS Code.
N5N3 and others added 27 commits March 30, 2023 08:57
There have been longstanding reasons to want an API for extracting
all extant specializations of a method, but this is even more
true after #49071.

Co-authored-by: Shuhei Kadowaki <[email protected]>
Co-authored-by: Jameson Nash <[email protected]>
For most applications the sample rate of 1/1000 is way too low. This will require manually setting a rate for production use, but IMO it's a lot better to make the default be taylored towards interactive/beginner use rather than deployment.
Add bit to the GC tag to turn GC in image search O(1) and also increase gc interval when encountering many pointers
`ismutationfree(Vector{Any})` is fixed in #48868, but there are other
array types that are instantiated within jltypes.c and thus annotated
as `ismutationfree` wrongly.
This commit fixes it up by covering all the builtin array types.
)

Even on BSD systems, if `date --version` succeeds and prints `GNU coreutils`, call it with GNU options.
This helps us prove `:nothrow`-ness of `arrayset` when bounds checking
is turned off manually.
This allows us to prove `:nothrow`-ness of `getfield` when bounds
checking is turned off manually.
It still taints `:nothrow` when a name of invalid type is given.
effects: assume `:nothrow`-ness more when bounds checking is manually turned off
Mostly by making use of newly added `:inaccessiblememonly` effect
property.
Now we can fold simple vector operations like:
```julia
julia> function simple_vec_ops(T, op!, op, xs...)
           a = T[]
           op!(a, xs...)
           return op(a)
       end;
simple_vec_ops (generic function with 1 method)

julia> for T = Any[Int,Any], op! = Any[push!,pushfirst!], op = Any[length,size],
           xs = Any[(Int,), (Int,Int,)]
           let effects = Base.infer_effects(simple_vec_ops, (Type{T},typeof(op!),typeof(op),xs...))
               @test Core.Compiler.is_foldable(effects)
           end
       end

julia> code_typed() do
           simple_vec_ops(Any, push!, length, Any,nothing,Core.Const(1))
       end
1-element Vector{Any}:
 CodeInfo(
1 ─     return 3
) => Int64
```
`Type`-object never has "undef" field and we should prove
`getfield` access to `Type`-object is `:consistent`.
By allowing cases when `Type`-objects are returned, e.g.:
```julia
@test Base.infer_effects((String,)) do a
    x = Ref(a)
    typeof(x)
end |> Core.Compiler.is_consistent
```
When it's applied to non-immutable object, we can taint `:consistent`-cy
by `CONSISTENT_IF_INACCESSIBLEMEMONLY` instead of `ALWAYS_FALSE`.
@aviatesk aviatesk requested review from DilumAluthge and a team as code owners April 2, 2023 11:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compiler:effects effect analysis don't squash Don't squash merge
Projects
None yet
Development

Successfully merging this pull request may close these issues.