dwblaikie wrote: Could you update the description to include an explanation of why the same uniqued type might end up in two distinct `DISubprogram`s under LTO? I guess/assume/vaguely recall it's probably due to internalizing those functions? (like they're inline functions and in one module one version gets internalized (so it can be specialized there - change the parameters, etc - say it has a dead/unused parameter, so it gets internalized and the parameter is removed) and in another module it gets internalized for similar reasons (maybe different enough they don't then get merged together because they don't end up identical))
> for each loaded distinct (definition) DISubprogram, its retainedNodes list is > scanned after loading, and DITypes with a scope of another subprogram are > removed. If something from a Function corresponding to the DISubprogram > references uniqued type, we rely on cross-CU links. So we'd end up with the two distinct versions of the DISubprogram, each emitted into their own CUs, but one will reference the type in another? Seems sort of fair/doesn't seem fundamentally wrong... > a check is added to Verifier to report about local types located in a wrong > retainedNodes list, Ah, OK, because now we won't do that - a local variable in one DISubprogram might reference a local type in another DISubprogram - but the type will only exist/be retained in one DISubprogram, the one it references as its own scope. Good good. Awkward, but good. https://github.com/llvm/llvm-project/pull/165032 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
