steakhal wrote: > In general, I tend to notice a pattern that `LazyCompoundVal` is too opaque > and its performance benefits come with lots of added code complexity as we > always need to explicitly check for it. (However I don't know enough, perhaps > this is still the least wrong approach.)
LCVs are complicated. However, having nonloc::CompoundVals only make this worse. If I had to choose today, I'd only have LCVs for representing compount vals. But note that I have a strong believe that LCVs are necessary for their laziness. I'm pretty sure though that we could have nice APIs around it that would bring consistency and no surprises. https://github.com/llvm/llvm-project/pull/164600 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
