PR #56293 points out a minor portability issue with the atoi,strtol, and strtoll folders as a result of relying on a nonportable aspect of strtoull for empty sequences. The issue is easy to avoid for just the limited subset of supported folders, but relying on srtroull turns out be problematic also due to overflow handling.
Rather than working around just the root cause of PR #56293, this patch replaces the use of strtoull with a hand-written conversion algorithm that doesn't suffer from either of these issues. Besides resolving the problem in the PR it enhances the libcall simplifier to handle the rest of the standard integer conversion functions.
In the PR @efriedma suggests using llvm::consumeSignedInteger. I ran into a couple of problems when trying that:
- The function recognizes other base prefixes besides 0 for octal and 0x for hex (0b for binary and 0o for octal), and these interfere with the rules of strtol. The prefixes would need to be disabled for the function to be usable in this context (e.g., by adding another argument).
- Like the current convertStrToNumber helper, the function doesn't make it possible to reliably detect whether or not the parsed number is representable in the destination type (which may be narrower than uint64_t). This too would require a change to the API to handle.
Rather than making intrusive changes to the existing "public" API I decided to instead modify the static helper function just for the libcall simplifier.
Besides the two problems noted above, llvm::consumeSignedInteger also doesn't strip leading space and succeeds even when the subject sequence isn't at the end of the string. Unlike those above, both of these could be handled by the caller.
Tested by running make check-all on x86_64-linux.
Couldn't it be simplified a bit to something like: Str = Str.drop_while([](char c) { return isSpace(c); }); ?