sepavloff added a comment. In https://reviews.llvm.org/D40508#938686, @rjmccall wrote:
> In https://reviews.llvm.org/D40508#938675, @sepavloff wrote: > > > In https://reviews.llvm.org/D40508#938040, @rjmccall wrote: > > > > > My skepticism about the raw_ostream is not about the design of having a > > > custom raw_ostream subclass, it's that that subclass could conceivably be > > > re-used by some other client. It feels like it belongs as an internal > > > hack in Clang absent some real evidence that someone else would use it. > > > > > > This class can be helpful in various cases where string identifier must > > persistently identify an object and memory consumption must be low. It may > > be: > > > > - If we introduce an option that allows a user to specify how many symbols > > of full type name are kept in abbreviated name, then `llvm-link` may see > > types named as `foo<int>` and `2544896211ff669ed44dccd265f4c9163b340190`, > > if they come from modules compiled with different options. To find out that > > these are the same type, it must have access to the same machinery. > > > The LLVM linking model does not actually depend on struct type names > matching. My understanding is that, at best, it uses that as a heuristic for > deciding whether to make an effort to unify two types, but it's not something > that's ultimately supposed to impact IR semantics. It is mainly true with an exception, when `llvm-link` resolves opaque types it relies on type name only. And this behavior creates the issue that https://reviews.llvm.org/D40567 tries to resolve. > If we needed IR type names to match reliably, we would use a mangled name, > not a pretty-print. There is no requirement for IR type name to be an identifier, so pretty-print fits the need of type identification. https://reviews.llvm.org/D40508 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
