labath wrote: > 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.
We can definitely add functions to covert (directly) between Scalars and ValueObjects (in fact, I think the only reason that the APInt overloads currently exists is because of the initial attempt to upstream the DIL implementation). However, I'm still not sure if it's necessary to ValueObjects for values internal to the expression. I don't think the different result type should be a problem since the result type for a given ast node kind should be always the same. Scalar nodes and all arithmetic operation should return a scalar, while other operations return a value object. If you need to use a value object in a scalar context (e.g. in `a[b]` where `b` is a variable) you add new node type (`LValueToRValueConversionNode` ?), which performs the extraction. > 2\. Still not sure how to sensibly get a compiler type for a given number. I > just did it by whatever size fits first. That's probably okay, though if we go down this path, it might not be *un*reasonable to create our own type system for representing these values. > 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. That might be something we can fix. What's the API you're using and what happens if you change it to do what you need? 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
