[libc-commits] [PATCH] D150567: [libc] Add optimized bcmp for RISCV

Guillaume Chatelet via Phabricator via libc-commits libc-commits at lists.llvm.org
Tue May 16 05:35:07 PDT 2023


gchatelet added inline comments.


================
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;
----------------
gchatelet wrote:
> gchatelet wrote:
> > sivachandra wrote:
> > > 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.
> > > 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.
> > 
> > `BcmpReturnType` is implicitly convertible from `uint32_t` by design. Since bool 
> > We could provide a `NONZERO` value though. The best value might be platform dependant.
> > Is this the correct check? Should we early-return on equality? IIUC, previously, it was doing an early return on XOR success.
> 
> The code is wrong indeed, I'm surprised that the tests didn't catch it. I'm investigating.
The tests did catch it, I just didn't rerun them after changing this line...


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