[PATCH] D120327: compiler-rt: Add udivmodei5 to builtins and add bitint library
Jacob Lifshay via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Wed Feb 23 10:54:30 PST 2022
programmerjake added a comment.
In D120327#3339898 <https://reviews.llvm.org/D120327#3339898>, @mgehre-amd wrote:
> In D120327#3338323 <https://reviews.llvm.org/D120327#3338323>, @programmerjake wrote:
>
>> As far as I can tell, this code seems to assume it's running on a little-endian system. I think it needs to correctly handle what happens when bigints are stored in the other endian (where the first word is the most-significant).
>
> Yes, that's a good observation. I don't have access to a big-endian system right now. Should I disable building those functions on big-endian systems for this PR?
probably...
>> Also, the division code seems to assume that the most-significant word is always non-zero or the whole value is zero, which would allow it to use the number of words as a proxy for how big the value is numerically, which isn't the case.
>
> Could you please tell me why you think that? I don't believe it's true, and I think the tests in divmodei5_test.c show that,
> specifically `if (test__divmodei5(2, 1, 2, 0, nbits, a_scratch, b_scratch, quo_scratch, rem_scratch))` does a 2/1 division on integers of various sizes.
I left an inline comment on one such place.
================
Comment at: compiler-rt/lib/builtins/udivmodei5.c:292
+ // special case: dividend is too small so quotient is always zero
+ if (lhsWords < rhsWords) {
+ if (Quotient) {
----------------
here's one place where the number of words is incorrectly assumed to be some indicator of numeric value
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D120327/new/
https://reviews.llvm.org/D120327
More information about the llvm-commits
mailing list