kuilpd wrote: > 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 (via > APFloat), so this would automatically get us floating point support.
@labath I did an experimental implementation of this, basically relying on Scalar to do all arithmetics for me, including type conversions and promotions. It works, even when adding Scalar(APInt) and Scalar(APFloat), but a couple of things are weird: 1. Constant wrapping/unwrapping of Scalar(APInt). For literals, it goes: parse as APInt -> wrap to Scalar to create a node -> unwrap APInt to create ValueObjectSP -> wrap to Scalar to use arithmetic operation -> unwrap APInt to create ValueObjectSP. Not sure if it's a problem or not, but there's no functionality to store a Scalar in ValueObject. 2. Still not sure how to sensibly get a compiler type for a given number. I just did it by whatever size fits first. Also, it looks like bit size of APInt that comes from a ValueObject is not reliable, since even a variable of type `char` has an APInt with 32 bit size. The best I could come up with is to recreate APInt with the size taken from compiler type. After that, type promotion in Scalar works as expected. 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
