Expose LLVM's or disjoint
instruction on ints
#373
Labels
ACP-accepted
API Change Proposal is accepted (seconded with no objections)
api-change-proposal
A proposal to add or alter unstable APIs in the standard libraries
T-libs-api
Proposal
Problem statement
When writing heavy bit-manipulating code you sometimes need to combine integers bitwise according to the following truth table:
a
b
combine(a, b)
The above truth table can be implemented using any of the following:
bitor
bitxor
add
and friendsWhich one you choose can have an impact on the performance of downstream code. Occasionally, you might want to exercise properties of more than one of these operations at the same time.
Motivating examples or use cases
Consider the construction of a mask like so:
let c = combine(a, b << 2);
. This comes up fairly often when dealing with packed data, for instance. Using+
forcombine
can result in a single instruction on x86:lea c, [a + b * 4]
. On the other hand, using|
allows LLVM to apply bitwise optimizations, such as remembering more known bits or tracking tighter bounds on the range ofc
.In projects which commonly utilize this operation, it would be beneficial to have a canonical way to write it. Due to the above concerns, however, this isn't always feasible, and a user attempting to maximize performance must take into account the tradeoffs every time.
Solution sketch
Expose LLVM's
or disjoint
instruction, which is the canonical way to write the above truth table. This takes the optimization burden off the programmer and shoves it onto LLVM, which is much better equipped to handle it.core::intrinsics::disjoint_or
, following the example ofcore::intrinsics::unchecked_add
and friends.NonZero
?) integers, like so:Alternatives
unreachable_unchecked
. LLVM does not recognize this right now. I assumed this is a very complicated problem - if it's not, then perhaps this is a better choice. I'm surprised this wasn't brought up in the unchecked math stabilization PR.Links and related work
Internals thread. Blog post about the introduction of the feature to LLVM.
The text was updated successfully, but these errors were encountered: