[PATCH] D123472: avoid slicing 64-bit integers in an ILP32 build (PR #54739)

[Martin Sebor via Phabricator via llvm-commits]

msebor created this revision.
msebor added reviewers: xbolva00, efriedma, nikic.
Herald added subscribers: pengfei, hiraditya.
Herald added a project: All.
msebor requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Passing a 64-bit result of a call like `Value::getZExtValue()` as an argument to `StringRef::substr()` in a 32-bit build truncates the value and, in the two test cases in bug 54739 <https://github.com/llvm/llvm-project/issues/54739>, leads to incorrect folding.  The attached change adjusts the calls to `StringRef::substr()` to avoid the truncation in these two instances.

I considered changing `StringRef::substr()` to use `uint64_t` but since the use of `size_t` in the `StringRef` API is pervasive and due to its interplay with `StringRef::npos` and sometimes `std::string::npos` and the potential for unintended semantic changes, decided against it.  I reviewed the rest of `SimplifyLibCalls.cpp` for similar problems and didn't spot any, but I suspect there may be others in the rest of the code base.

Tested on x86_64-linux in ILP32 and LP64 modes.  (The ILP32 test run shows a few crashes that appear unrelated to this change.)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D123472

Files:
  llvm/lib/Transforms/Utils/SimplifyLibCalls.cpp
  llvm/test/Transforms/InstCombine/memchr-4.ll
  llvm/test/Transforms/InstCombine/strncmp-3.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D123472.421810.patch
Type: text/x-patch
Size: 7002 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20220410/6b8603a8/attachment.bin>