[libc-commits] [PATCH] D137871: [libc][math] Improve the performance and error printing of UInt.
Siva Chandra via Phabricator via libc-commits
libc-commits at lists.llvm.org
Mon Nov 14 12:04:25 PST 2022
sivachandra added inline comments.
================
Comment at: libc/src/__support/UInt.h:24
-template <size_t Bits> class UInt {
+template <size_t Bits> struct UInt {
----------------
lntue wrote:
> michaelrj wrote:
> > is there a reason this is changed?
> I put everything in this class as `public` for 3 reasons:
> - To access to `WordCount` without recomputing it
> - To make this class behave as a value class, I'm going to remove the `operator[]`, and simply use `.val[i]` directly if we want to access to its ith `uint64_t` block.
> - Utility functions `low` and `high` (and `MASK32` constant) will be removed and switched completely to use `split(uint64_t)` instead. That would separate what we want to do with the class vs what we want to do with `uint64_t`.
> I put everything in this class as `public` for 3 reasons:
> - To access to `WordCount` without recomputing it
You can make that public alone?
> - To make this class behave as a value class, I'm going to remove the `operator[]`, and simply use `.val[i]` directly if we want to access to its ith `uint64_t` block.
Whats wrong with `operator[]` for such word access?
> - Utility functions `low` and `high` (and `MASK32` constant) will be removed and switched completely to use `split(uint64_t)` instead. That would separate what we want to do with the class vs what we want to do with `uint64_t`.
I did not get how this is related to `class` vs `struct`.
================
Comment at: libc/src/__support/number_pair.h:37
+
+template <typename T> number_pair<T> full_mul(T a, T b);
+
----------------
The `full_mul` functions should not belong here or name this file something else. May be `integer_utils.h`.
================
Comment at: libc/utils/UnitTest/LibcTest.cpp:281
+template bool test<__llvm_libc::cpp::UInt<192>>(
+ RunContext *Ctx, TestCondition Cond, __llvm_libc::cpp::UInt<192> LHS,
----------------
Ideally, these specializations should be in a different file, say `integer_test_utils.cpp`, right next to where `UInt` is defined. May be it leads to a CMake cyclic directory problem?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D137871/new/
https://reviews.llvm.org/D137871
More information about the libc-commits
mailing list