dgg5503 wrote: > I agree that it's important to augment the bug reports with information about > the source of the symbols. Especially for conjured and derived symbols that > are produced widely because of invalidations. Loop widening is just one > source of invalidation, and we could generalize it slightly. > > Read this post of mine: > https://discourse.llvm.org/t/memory-region-invalidation-tracking-improvements/62432 > Unfortunately, I never got to implement it, but I'd be very happy as a > reviewer to guide you through.
Hi @steakhal , I'm happy to hear others share a similar concern! I agree that it would make more sense to generalize this beyond loop widening. However, I'm having a hard time understanding how your proposal would fit in to the augmentation of the assignment message like I do in this PR. The part I'm most confused about is how would `SymbolInvalidationArtifact` be set/retrieved after invalidation occurs? Would this somehow be tied to symbols created as part of invalidation (like created conjured symbols in `InvalidateRegionsWorker::VisitCluster`) which could then be retrieved via `SI.Value.getAsSymbol()` and casting (speaking from the PoV of `showBRDiagnostics`)? I think I would better understand if you could please provide a small example in the context of diagnostic output. I'm fairly certain I'm lacking understanding of some static analysis design concept that's not making this click in my head... Regardless, once I have a better understanding of how your proposal fits in, I'd be happy to give your approach a try with your guidance :). Thank you https://github.com/llvm/llvm-project/pull/122398 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
