steakhal wrote: > `<offtopic>` @steakhal > > > However, having nonloc::CompoundVals only make this worse. > > Technically I didn't claim that they are better 😅, and I can easily believe > that they are indeed worse... > > > If I had to choose today, I'd only have LCVs for representing compount vals. > > I think non-lazy compound values are necessary from a theoretical POV to > cover cases where we want to create a compound value directly (without > "building it up" gradually in a state). For example, assume that we need to > write an `EvalCall` for a function that construct a class object and returns > it by value: this return value (which we want to bind into the `Environment`) > is a compound value which cannot be expressed as a lazy compound value > (because it is not the contents of a memory region that we model). (I admit > that I don't know about a use case where we actually need an `EvalCall` like > this.)
As I understand this, the refcounted Store object doesn't need to be built up gradually. You can create a Store object for your liking and then set your LCV to refer to that Store. That's true that what LCVs are currently built up gradually, but that's because we have regular compound vals that take that use case where we would create a branch new Store object in a single step, holding each binding. https://github.com/llvm/llvm-project/pull/164600 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
