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

Reply via email to