update to root. #3
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Use box-drawing characters and indentation to make the output readable more rapidly.
…_native For consistency of user experience, reduce the variance in our IR printing across formats. This also now shows inlining and line number information even if the output device might not support color, which was previously impossible (a regression since v0.6).
Here we make the observation that it's somewhat common to have chains of methods of one function that recursively handle arguments in some fashion (for example, map-tuple or +). However, since they all have the same method name, it's possible to represent these on a single line.
prettier IR-show for line number and inlining information
libunwind patch releases like 1.2.1 have UNW_VERSION_MINOR = 2.1, which makes the comparison fail. Use a more robust comparison which excludes all versions between 1.0 and 1.2 instead. https://savannah.nongnu.org/bugs/index.php?52529
* Iterate over smaller set for setdiff[!] * Add comment and change to integer multiplication
I don't have time to do this whole document, but it could do with an edit by a native English speaker.
Fixed by the new optimizer. This closes #26729.
closes #26037
Copying the mark stack struct instead of aliasing it ensures that structural replacement of aggregates for its members can still take place in the mark loop.
Since the edge list of a phi may be incomplete with respect to predecessors, it is not safe to replace a one-value phi by its value, unless we know that there is only one predecessor. Remove the incorrect logic from domsort. We do also do the correct transformation in compaction right afterwards these days.
The i-search prompt becomes for example: `(failed forward-i-search)`.
This commit replaces the naive algorithm for replacing dominator trees by a faster implementation based on the Semi-NCA algorithm (reference in the code comments). LLVM recently switched to this algorithm and found it to be faster in practice than SLT (which it used before). It is also slightly easier to implement. More importantly though, it should easily extend to dynamic dominators. This fixes the preformance problems in dominator construction noted in #25927 and should provide a basis for a dynamic dominator implementation to fix #29107.
* at-kwdef support for parametric types and subtypes Fixes #29307.
GC Extensions
The parent link can unnecessarily hold memory references live, and the current-module function is gone. Their uses have been deprecated in favor of the macros @`__FILE__` and @`__MODULE__`. The `workspace()` function is also gone now, so we can remove the support code for it. To implement detection of broken incremental compilation (and help ensure the module is permanently rooted as is generally expected), keep track of all "open" modules in a hashtable (jl_current_modules). We can further refine this later, if desired (e.g. also allow any submodule and of any item in `jl_module_init_order`). Also removes the global `module_stack` state. This makes us a bit more robust to async module definition. We could perhaps do even more here, if necessary (e.g. by checking first that all parents are initialized, instead of just the direct ancestor). But this is hopefully a vanishingly rare situation anyways.
* mul!, rmul! and lmul! methods for UniformScaling As per https://discourse.julialang.org/t/in-place-multiplication-methods-for-uniformscaling-type/15837 * Add tests and another mul! method
…ment for "partially constant" tuples Previously, we hacked in an additional `InferenceResult` field to store varargs type information in order to facilitate better constant propagation through varargs methods. There were many other places, however, where constants moving in/out of tuples/varargs thwarted constant propagation. This commit removes the varargs hack, replacing it with a new inference lattice element (`PartialTuple`) that represents tuples where some (but not all) of the elements are constants. This allows us to follow through with constant propagation in more situations involving tuple construction/destructuring, and also enabled a clean-up of the `InferenceResult` caching code.
E.g. if we had `PiNode(1, CartesianIndex)`, we would eliminate that because `1` was a constant. However, leaving this in allows the compiler to realize that this code is unreachable, as well as guarding codegen against having to wrok through invalid IR.
Unfortunately, we cannnot always rely on :invokes to have argument values that match the declared ssa types (e.g. if the :invoke is dynamically unreachable). Because of that, we cannot assert here, but must instead emit a runtime trap.
My apologies if this small edit is somewhere else waiting to be merged. I couldn't find it...
nagexiucai
pushed a commit
that referenced
this pull request
May 6, 2019
Consider the following function:
```
julia> function foo(a, b)
ntuple(i->(a+b; i), Val(4))
end
foo (generic function with 1 method)
```
(In particular note that the return type of the closure does not depend on the types
of `a` and b`). Unfortunately, prior to this change, inference was unable to determine
the return type in this situation:
```
julia> code_typed(foo, Tuple{Any, Any}, trace=true)
Refused to call generated function with non-concrete argument types ntuple(::getfield(Main, Symbol("#JuliaLang#15#16")){_A,_B} where _B where _A, ::Val{4}) [GeneratedNotConcrete]
1-element Array{Any,1}:
CodeInfo(
1 ─ %1 = Main.:(#JuliaLang#15#16)::Const(#JuliaLang#15#16, false)
│ %2 = Core.typeof(a)::DataType
│ %3 = Core.typeof(b)::DataType
│ %4 = Core.apply_type(%1, %2, %3)::Type{#JuliaLang#15#16{_A,_B}} where _B where _A
│ %5 = %new(%4, a, b)::#JuliaLang#15#16{_A,_B} where _B where _A
│ %6 = Main.ntuple(%5, $(QuoteNode(Val{4}())))::Any
└── return %6
) => Any
```
Looking at the definition of ntuple
https://github.com/JuliaLang/julia/blob/abb09f88804c4e74c752a66157e767c9b0f8945d/base/ntuple.jl#L45-L56
we see that it is a generated function an inference thus refuses to invoke it,
unless it can prove the concrete type of *all* arguments to the function. As
the above example illustrates, this restriction is more stringent than necessary.
It is true that we cannot invoke generated functions on arbitrary abstract
signatures (because we neither want to the user to have to be able to nor
do we trust that users are able to preverse monotonicity - i.e. that the return
type of the generated code will always be a subtype of the return type of a more
abstract signature).
However, if some piece of information is not used (the type of the passed function
in this case), there is no problem with calling the generated function (since
information that is unnused cannot possibly affect monotnicity).
This PR allows us to recognize pieces of information that are *syntactically* unused,
and call the generated functions, even if we do not have those pieces of information.
As a result, we are now able to infer the return type of the above function:
```
julia> code_typed(foo, Tuple{Any, Any})
1-element Array{Any,1}:
CodeInfo(
1 ─ %1 = Main.:(##3#4)::Const(##3#4, false)
│ %2 = Core.typeof(a)::DataType
│ %3 = Core.typeof(b)::DataType
│ %4 = Core.apply_type(%1, %2, %3)::Type{##3#4{_A,_B}} where _B where _A
│ %5 = %new(%4, a, b)::##3#4{_A,_B} where _B where _A
│ %6 = Main.ntuple(%5, $(QuoteNode(Val{4}())))::NTuple{4,Int64}
└── return %6
) => NTuple{4,Int64}
```
In particular, we use the new frontent `used` flags from the previous commit.
One additional complication is that we want to accesss these flags without
uncompressing the generator source, so we change the compression scheme to
place the flags at a known location.
Fixes JuliaLang#31004
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.