This is an archive of the discontinued LLVM Phabricator instance.

[KnownBits] Simplify shl. NFCI.
ClosedPublic

Authored by foad on May 25 2023, 4:07 AM.

Diff Detail

Event Timeline

foad created this revision.May 25 2023, 4:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 25 2023, 4:07 AM
foad requested review of this revision.May 25 2023, 4:07 AM
Herald added a project: Restricted Project. · View Herald TranscriptMay 25 2023, 4:07 AM
foad added a subscriber: nikic.

@nikic this was a result of me trying to understand your implementation. I tried to:

  • remove special cases (but perhaps some of these were deliberate early-outs to speed up to the common cases?)
  • work in unsigned instead of APInt as much as possible
  • take advantage of APInt::*shl_ov
nikic added a comment.May 25 2023, 5:06 AM

@nikic this was a result of me trying to understand your implementation. I tried to:

  • remove special cases (but perhaps some of these were deliberate early-outs to speed up to the common cases?)

Yes, these are intentional fast paths. In fact, the ones we currently have are insufficient, and we'll need another one for the case where the shift amount is unknown, because the current implementation is too slow. (This path is mostly not exposed right now due to special code in ValueTracking, but it if does get exposed it causes substantial compile-time regressions.)

It's possible that dropping the special handling for constants would be fine, but we need to at least keep the code for handling unknown LHS.

  • work in unsigned instead of APInt as much as possible
  • take advantage of APInt::*shl_ov

These changes look good to me and should make the implementation faster.

nikic added a comment.May 25 2023, 6:40 AM

@nikic this was a result of me trying to understand your implementation. I tried to:

  • remove special cases (but perhaps some of these were deliberate early-outs to speed up to the common cases?)

Yes, these are intentional fast paths. In fact, the ones we currently have are insufficient, and we'll need another one for the case where the shift amount is unknown, because the current implementation is too slow. (This path is mostly not exposed right now due to special code in ValueTracking, but it if does get exposed it causes substantial compile-time regressions.)

For reference, that extra fast path is going to look something like this: https://github.com/llvm/llvm-project/commit/6c242bc3d81f87b819e6d705d73a43fb4bf1c5d0 (Which does fix the compile-time regressions.) But I'll return to this once you're done with your changes.

foad updated this revision to Diff 525592.May 25 2023, 7:23 AM

Restore and simplify the fast path for unknown LHS.

nikic accepted this revision.May 25 2023, 7:31 AM

LGTM

llvm/lib/Support/KnownBits.cpp
210–214

Seems like pulling this out of the isUnknown() branch would be cleaner, as it is not specific to unknown values.

This revision is now accepted and ready to land.May 25 2023, 7:31 AM
foad added inline comments.May 25 2023, 7:57 AM
llvm/lib/Support/KnownBits.cpp
210–214

Yeah, maybe. This was a result of me trying to work out why this code is required, and it's only required in the LHS.isUnknown() case, otherwise it will naturally fall out in the wash. And since it will almost never happen in practice, I chose to keep it out of the main code path.

210–214

It is also only required in order to guarantee that we return zero for poison results. I've just put D151456 to check that property so we don't regress it.

This revision was landed with ongoing or failed builds.May 25 2023, 8:05 AM
This revision was automatically updated to reflect the committed changes.