[libc-commits] [PATCH] D150567: [libc] Add optimized bcmp for RISCV
Siva Chandra via Phabricator via libc-commits
libc-commits at lists.llvm.org
Mon May 15 10:54:30 PDT 2023
sivachandra added inline comments.
================
Comment at: libc/src/string/memory_utils/bcmp_implementations.h:27
LIBC_LOOP_NOUNROLL
- for (size_t offset = 0; offset < count; ++offset)
- if (auto value = generic::Bcmp<1>::block(p1 + offset, p2 + offset))
----------------
What was `offset` previously? Was this dead code?
================
Comment at: libc/src/string/memory_utils/bcmp_implementations.h:28
+ for (; offset < count; ++offset)
+ if (uint32_t value = (p1[offset] == p2[offset]))
return value;
----------------
s/`uint32_t`/`BcmpReturnType` ? I think it might not compile? May be a cleaner approach would be to provide a `BcmpReturnType::TRUE` and `BcmpReturnType::FALSE`, or may be `BmpReturnType::ONE`.
================
Comment at: libc/src/string/memory_utils/bcmp_implementations.h:28
+ for (; offset < count; ++offset)
+ if (uint32_t value = (p1[offset] == p2[offset]))
return value;
----------------
sivachandra wrote:
> s/`uint32_t`/`BcmpReturnType` ? I think it might not compile? May be a cleaner approach would be to provide a `BcmpReturnType::TRUE` and `BcmpReturnType::FALSE`, or may be `BmpReturnType::ONE`.
Is this the correct check? Should we early-return on equality? IIUC, previously, it was doing an early return on XOR success.
================
Comment at: libc/src/string/memory_utils/bcmp_implementations.h:56
+ if (a != b)
+ return 1U;
+ }
----------------
Same here: `1U` need not always be of `uint32_t` type.
================
Comment at: libc/src/string/memory_utils/bcmp_implementations.h:81
+ if (a != b)
+ return 1U;
+ }
----------------
And here.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D150567/new/
https://reviews.llvm.org/D150567
More information about the libc-commits
mailing list