rnk wrote:
I apologize I haven't carefully read @ojhunt 's self-admitted wall of text, but
it seems to me like a possible next step would be to set up a call to come up
with some acceptable compromise.
My high-level input is, I wonder if Oliver's concerns about `__wrap` can be
fixed by using more precise math-y naming by invoking the word "modular", or
"mod2". Yeah, I know, it's bikeshedding, but names are important, they are the
essentially unskippable documentation. As a reader, this seems like the meaning
of the examples you are passing back and forth would be clearer:
```
uint8_t __mod2 x = ...;
if (x + 1 == 0) { ... } // Is there a special case to narrow integer literals?
...
uint64_t u64 = 1ull<<32;
uint32_t __mod2 u32 = 1;
u64 = u64 + u32; // Do we widen u32, and then do a `+mod2` operation?
// Does the assignment from `uint64_t __mod2` allow implicit conversion?
```
If you think about the canonical use case for intentional unsigned integer
overflow, it's probably cryptographic algorithms, where the algorithms are
usually defined in terms of modular arithmetic. If we call it that, something
math-y programmers will be less likely to reach for the feature when they are
simply trying to implement an overflow check.
---
As for `__nowrap`, my imperfect understanding is that it basically constrains
the implementation to either behave as `-fwrapv` or `-ftrapv`. It would be
incorrect to apply LLVM `nsw` / `nuw` qualifiers to the resulting math
instructions.
https://github.com/llvm/llvm-project/pull/148914
_______________________________________________
lldb-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
