[libc-commits] [libc] [libc][stdfix] Fix idiv* doc table, rename idivfx test helpers and remove duplicate bitsuk source (PR #206729)
via libc-commits
libc-commits at lists.llvm.org
Sun Jul 5 07:52:08 PDT 2026
sohail103 wrote:
also i talked to @lntue about this cleanup during the libc math meeting and he mentioned adding NA to the stdfix table entries that aren't applicable. i'm wondering if this applies to idivfx for uhr, hr, uhk, hk (signed and unsigned variants of short fract and accum). the TR18037 document doesn't mention these variants as quoted below:
```
According to the rules above, the result type of an arithmetic operation where one operand has a fixed-point type and the other operand has an integer or a fixed-point type is always a fixed-point type. Other combinations of operand and result types for arithmetic operations are supported through special functions. The names for these functions are mulifx, divifx, fxdivi and idivfx, where fx stands for one of r, lr, k, lk, ur, ulr, uk and ulk. The muli functions multiply an integer operand by a fixed-point operand and return an integer value; the divi functions divide the first (integer) operand by a fixed-point operand (divifx) yielding an integer type result, or divide two integer operands (fxdivi) yielding a fixed-point type result; the idivfx functions divide the two fixed-point type operands (with the same type) and return an integer result. If an integer result of one of these functions overflows, the behavior is undefined.
```
should i mark these as NA in this case since the TR doesn't define them? is the main reason for the TR not mentioning these the fact that they might not be used as often? or do we want to add these implementations sometime since at least in these cases its probably fairly straightforward to implement these anyway?
https://github.com/llvm/llvm-project/pull/206729
More information about the libc-commits
mailing list