labath wrote: > > but I can also imagine doing something like python's "arbitrary width" > > integers. > > Isn't this basically `llvm::APInt` class?
Sort of, but not quite. APInt has an arbitrary but fixed width. Python integers scale their width dynamically to fit the result (so they sort of have "infinite width"). We could emulate that using APInt by scaling its width before an operation sufficiently so that it does not lose precision, but I would actually rather not -- mainly because we would have to implement wrapper class for that, but also because it avoids some pathological cases if a user accidentally does a `1<<UINT_MAX` or something. However, that means we still need to define what happens in case of overflows, width mismatches, and such. Two easy ways to do that would be: 1. say that values retain their width and signedness, but then get converted into the wider width using C-like rules. We already have this implemented inside the Scalar class (which wraps APInt), so this would be best in terms of code reuse, and it would produce few surprises to people used to C arithmetic. The Scalar class also supports floating point numbers, so this would automatically get us floating point support. 2. Say that all operations happen on large-but-fixed-width types. For example, 128-bit integers and IEEE quad floats? We could still use the Scalar class for this, but promote the value to the desired type before doing anything. https://github.com/llvm/llvm-project/pull/147064 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
