haoNoQ wrote: Ahhh good catch.
Yeah right now `SymbolDerived` treats the conjured symbol inside it as the timestamp of the devastating event that caused the loss of information about the program state. So the region needs to do all the heavy lifting of figuring out which part of the lost information is being pulled. In this sense `SymbolRegionValue` is effectively a `SymbolDerived` that corresponds to the devastating event of starting the analysis from an arbitrary function in the middle of the program. So right now it doesn't make sense to "transplant" the conjured symbol because the recepient region wasn't actually devastated by that event. And the connection between the event and the affected region is currently completely implicit. (See also the funny symbol dumps in https://godbolt.org/z/jovxGYo7z) I completely agree that all the heavy lifting needs to be performed by the conjured symbol instead, and the derived symbol should just be an offset into it. Then the transplant would make a lot more sense. It's slightly different with global variables and heap regions where the conjured symbol covers the entire memory *space*. Eg. the variable itself acts as the offset with respect to the entire space of global variables. So in this case the derived symbol needs to carry at least some region information. But in that case you probably don't want to transplant the conjured symbol across memory spaces in the first place. That said, I'm not sure where I stand on the overall idea of transplanting symbols to save on indirections. Are indirections *that* annoying/expensive to unwrap? It's not like lazy compound values are expensive to create. It's very annoying in terms of checker API but this could probably solved by simply providing convenient API? I need to read more about your previous patches to catch up on that. https://github.com/llvm/llvm-project/pull/163461 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
