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

Ensure that BitArrays are inferrable for arbitrary Integer #37082

Merged
merged 3 commits into from
Aug 26, 2020

Conversation

timholy
Copy link
Sponsor Member

@timholy timholy commented Aug 17, 2020

BitArray operations are frequently performed with partial inference information (particularly from Pkg but others as well). Currently the internal operations are a source of invalidation for common arithmetic and bitwise operators. There seems to be no need to live with this, as all the inference problems are fixed by converting Integers to Ints. This is done elsewhere already in BitArray code, so it only seems to be continuing a process that is already underway.

Because of the multiplicity of methods BitArray{N}(a::Any) is not fully inferrable but there are at least limited victories, and the real benefits are in the elimination of instabilities in the internal operations.

@timholy timholy added arrays [a, r, r, a, y, s] compiler:latency Compiler latency labels Aug 17, 2020
base/bitarray.jl Outdated Show resolved Hide resolved
base/bitarray.jl Outdated Show resolved Hide resolved
base/bitarray.jl Outdated Show resolved Hide resolved
base/bitarray.jl Outdated Show resolved Hide resolved
BitArray operations are frequently performed with partial inference
information (particularly from Pkg but others as well).
Currently the internal operations are a source of invalidation for
common arithmetic and bitwise operators. There seems to be no need
to live with this, as all the inference problems are fixed by
converting `Integer`s to `Int`s. This is done elsewhere already in
BitArray code, so it only seems to be continuing a process that is
already underway.

Because of the multiplicity of methods `BitArray{N}(a::Any)` is not
fully inferrable but there are at least limited victories,
and the real benefits are in the elimination of instabilities
in the internal operations.
Copy link
Sponsor Member

@KristofferC KristofferC left a comment

Choose a reason for hiding this comment

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

There are a few more functions that could split out the Int conversion but maybe they are considered small so it doesn't really matter.

@@ -933,6 +947,7 @@ function _deleteat!(B::BitVector, i::Integer)
end

function deleteat!(B::BitVector, i::Integer)
i = Int(i)
Copy link
Sponsor Member

Choose a reason for hiding this comment

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

Could do the "split out the Int conversion part"-dance here as well.

Copy link
Sponsor Member Author

Choose a reason for hiding this comment

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

My feeling is the bit of bounds-checking isn't worth worrying about.

@timholy timholy merged commit b0ab29e into master Aug 26, 2020
@timholy timholy deleted the teh/infer_bitarray branch August 26, 2020 12:25
simeonschaub pushed a commit to simeonschaub/julia that referenced this pull request Aug 29, 2020
…ng#37082)

BitArray operations are frequently performed with partial inference
information (particularly from Pkg but others as well).
Currently the internal operations are a source of invalidation for
common arithmetic and bitwise operators. There seems to be no need
to live with this, as all the inference problems are fixed by
converting `Integer`s to `Int`s. This is done elsewhere already in
BitArray code, so it only seems to be continuing a process that is
already underway.

Because of the multiplicity of methods `BitArray{N}(a::Any)` is not
fully inferrable but there are at least limited victories,
and the real benefits are in the elimination of instabilities
in the internal operations.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
arrays [a, r, r, a, y, s] compiler:latency Compiler latency
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants