sepavloff added a comment. In https://reviews.llvm.org/D40508#937212, @rjmccall wrote:
> In Swift's IRGen, we have an option controlling whether to emit meaningful > value names. That option can be set directly from the command line, but it > defaults to whether we're emitting IR assembly (i.e. .ll, not .bc), which > means that the clients most interested in getting meaningful value names — > humans, presumably — always get good names, but nobody else pays for them. I > have many, many times wished that we'd taken that same approach in Clang > instead of basing it on build configuration. > > If type names are a significant burden on compile times, should we just start > taking that same approach? Just don't use real type names in .bc output > unless we're asked to. Maybe we can eventually retroactively use the same > option for value names. This is indeed reasonable approach, I will implement it the subsequent patch. Actually we could vary name length to achieve better readability or same memory, as the hash is calculated for entire type name and remains the same. > I agree with Reid that it's really weird for there to be a raw_ostream that > automatically rewrites the string contents to be a hash when some limit is > reached; that does not feel like generalizable technology. It reduces type names and at the same time keeps type uniqueness across TUs. It also does not require massive changes in printing methods. Probably the intent will be more clear when I publish the next patch of this set. https://reviews.llvm.org/D40508 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
