rsmith added a comment. In https://reviews.llvm.org/D43578#1067879, @avt77 wrote:
> In https://reviews.llvm.org/D43578#1067768, @rsmith wrote: > > > Last time I looked at doing this, I found that LLVM's timer infrastructure > > was fundamentally unsuitable for adding timers like these to Clang. > > > Thank you for this answer. As I understand we should close both this review > and https://reviews.llvm.org/D45619 I think https://reviews.llvm.org/D45619 is a good change, and I'd like to see that get committed. If LLVM's timer infrastructure can be improved to correctly track time in recursive and mutually-recursive timing regions (and I believe it can be), we could continue with this patch; if you want to pursue that, my first questions would be: Who is the audience for this information? What information do they want from a time report? How do we present that information in a way that's not misleading (given Clang's architecture)? Can we deliver useful value compared to a modern, dedicated profiling tool? > but you'd like to see something like MS has here > <https://aras-p.info/blog/2017/10/23/Best-unknown-MSVC-flag-d2cgsummary/>, > right? Yes, that's the kind of information I think we should be looking at adding here -- I think that's exactly what Clang users would be looking for when they reach out to a compilation time report to try to figure out why their compile is slow. https://reviews.llvm.org/D43578 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
