jmorse wrote: > Ah, fair enough, because the subprogram will contian a list of these local > types, then the local type's scope will be a (potentially series of) lexical > scope - so the lexical scopes are preserved?
That's certainly the outcome that the original patch series is aiming for -- I'm not completely certain that we can still achieve it. Part of the patch series clones types contained within distinct DISubprograms `retainedNodes` when they're inlined, which suggests that there's a connection between the types and the duplicated/distinct scopes that must be maintained, something that this patch would damage. I suppose I should hold off landing this patch until I fully understand that mechanism, and check we can still reach the desired outcome. > > Given that the ODR-uniquing issue was only found experimentally > > in-the-field, I think we have to accept the incremental approach and > > discover problems by experience. > > Not sure I follow this. I mean: at some point we just have to commit code and see what breaks, to discover obscure requirements. > > Stepping back slightly: I think the ODR-uniquing of these types is directly > > opposed to scope-precision: reducing the number of type definitions down to > > one necessarily means discarding the extra locality information about where > > it's scoped in different function instances. > > Not sure I follow this either - I think that if each concrete lexical scope > references the abstract ones, we could emit correct abstract origins to get > the local static variables and types to be scoped appropriately in the > resulting DWARF/for the consumer. Indeed, if that connection is present then we should be fine. I'm worried that some of the extra plumbing (i.e. the cloning-of-types-during-inlining) indicates that this property requires maintenance during optimisation, and that that maintenance could be impossible in the presence of the ODR-uniquing feature. https://github.com/llvm/llvm-project/pull/119001 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits