Closed alion02 closed 1 month ago
Discussed in today's libs-api meeting. Approved, but please use disjoint_bitor
for the intrinsic and unchecked_disjoint_bitor
for the non-intrinsic function.
unchecked_disjoint_bitor
conflicts with the API guidelines. Could I suggest naming it disjoint_bitor_unchecked
instead?
tbh that naming seems kinda backwards to me, I prefer bitor_disjoint_unckecked
But unchecked first makes it consistent with the recently stabilized unchecked_{add,sub,mul}
methods on integers. Which seems more valuable
Closing since this ACP has been approved, discussion should move to the PR/tracking issue.
Proposal
Problem statement
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.