mtrofin wrote: > > > It looks like this causes a compile-time regression, esp. for ThinLTO: > > > https://llvm-compile-time-tracker.com/compare.php?from=e0ef143823ce8f733c50fae675f05d0df0f702e5&to=7938535a54b51a4ca84821b7766d68049c9aa895&stat=instructions:u > > > Can you please investigate what the cause of the issue is? This doesn't > > > seem like a change that should impact compile-time if implemented > > > correctly. > > > > > > I was able to repro for the file causing the largest relative regression - > > libclamav_entconv (1.67% more instructions retired), in the ReleaseThinLTO > > config. > > Turns out it has lots of globals, and just 7, not particularly large, > > functions. The result is a large number of global values to write to the > > global summary, and also lots of guids. The function bodies aren't > > particularly large, though, so the extra bitcode writing because of the > > guids is detectable. > > I don't think this is the whole story. This causes a ~0.3% regression during > the thin link of clang (and llvm-tblgen / clang-tblgen), and those are > certainly not workloads dominated by globals. This seems like a pretty across > the board regression for ThinLTO.
It would be visible during ThinTLO mainly, since that's when we'd write summaries which now contain an extra table, but I agree that confirming that's all we're seeing is a good idea. How do the clang builds get measured by the compile time tracker, `perf stat` or it runs everything (the whole ninja build) in valgrind? (one thing I noticed in the ninja traces is that one job has more threads, and some instruction count overhead might be just from synchronization maybe - so I'd want to do a bunch of repeated measurements and see what the noise is) https://github.com/llvm/llvm-project/pull/184065 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
