Date: Sat, 17 Feb 2024 21:27:28 +0000
FYI, I have created a small google test play area here: https://github.com/tmiguelf/cast_changes_value_test.git
You can check implementation alternatives against it.
> Even though you can implement it yourself in terms of div_wide, I'd still argue that there should be a separate function that does it for you. GCC and clang would likely implement that in terms of an __int128 division, which would be better for debug builds and constant evaluations than having the user create their own wrapper function which calls div_wide multiple times.
>It's also not 100% obvious that you can use long division to implement it in terms of div_wide. It may be obvious to the implementer, but not to the user.
>Note that for GCC and clang, both the signed 128-to-64-bit division calls __modti3 and the unsigned counterpart calls __umodti3. It may be difficult to achieve that kind of codegen when the optimizer has to assemble multiple div_wide calls that collectively form a 128-bit remainder operation.
The functions that I have suggested (except for checks), even if not in all CPUs, there is a CPU with such an instruction. Functions like what you are suggesting would always need to be written as a function.
I really would like to avoid adding more content that I would have to defend in front of the committee if I personally don't understand its use case.
Maybe if you can give me an example (github page?) of an algorithm of where that function would be used I can consider.
But given that the implementation looks like this https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/udivmodti4.c, and not 2 lines of assembly + move, it doesn't look promising, I'm afraid it maybe making the typical mistake of using the uint128_t as an intermediary step to do wide arithmetic and ending up with that big mess because uint128_t /uint128_t is much more complicated than uint128_t /uint64_t. That is a recurrent problem that I aim to resolve with this paper.
Send me a link to the algorithm and I will have a look.
You can check implementation alternatives against it.
> Even though you can implement it yourself in terms of div_wide, I'd still argue that there should be a separate function that does it for you. GCC and clang would likely implement that in terms of an __int128 division, which would be better for debug builds and constant evaluations than having the user create their own wrapper function which calls div_wide multiple times.
>It's also not 100% obvious that you can use long division to implement it in terms of div_wide. It may be obvious to the implementer, but not to the user.
>Note that for GCC and clang, both the signed 128-to-64-bit division calls __modti3 and the unsigned counterpart calls __umodti3. It may be difficult to achieve that kind of codegen when the optimizer has to assemble multiple div_wide calls that collectively form a 128-bit remainder operation.
The functions that I have suggested (except for checks), even if not in all CPUs, there is a CPU with such an instruction. Functions like what you are suggesting would always need to be written as a function.
I really would like to avoid adding more content that I would have to defend in front of the committee if I personally don't understand its use case.
Maybe if you can give me an example (github page?) of an algorithm of where that function would be used I can consider.
But given that the implementation looks like this https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/builtins/udivmodti4.c, and not 2 lines of assembly + move, it doesn't look promising, I'm afraid it maybe making the typical mistake of using the uint128_t as an intermediary step to do wide arithmetic and ending up with that big mess because uint128_t /uint128_t is much more complicated than uint128_t /uint64_t. That is a recurrent problem that I aim to resolve with this paper.
Send me a link to the algorithm and I will have a look.
Received on 2024-02-17 21:27:30