Page MenuHomePhabricator

[codeview] Expose -gcodeview-ghash for global type hashing
ClosedPublic

Authored by rnk on Nov 9 2018, 5:19 PM.

Details

Summary

Experience has shown that the functionality is useful. It makes linking
optimized clang with debug info for me a lot faster, 20s to 13s. The
type merging phase of PDB writing goes from 10s to 3s.

This removes the LLVM cl::opt and replaces it with a metadata flag.

After this change, users can do the following to use ghash:

  • add -gcodeview-ghash to compiler flags
  • replace /DEBUG with /DEBUG:GHASH in linker flags

Diff Detail

Repository
rL LLVM

Event Timeline

rnk created this revision.Nov 9 2018, 5:19 PM
aganea added a subscriber: aganea.Nov 10 2018, 2:58 PM
takuto.ikuta accepted this revision.EditedNov 10 2018, 7:32 PM

This change makes sense to me.
But I want chromium config will be updated in next clang roll.
https://cs.chromium.org/chromium/src/build/config/compiler/BUILD.gn?l=2210&rcl=c1582e69def506093836a7cc6ba1e9c77c3b7a69

This revision is now accepted and ready to land.Nov 10 2018, 7:32 PM
aganea added a comment.EditedNov 11 2018, 8:32 AM

@rnk Could you possibly post build metrics for Chromium (for the whole build process, compilation and link) with and without ghash?
In my early tests, it seemed that on a large project, compilation was a bit slower overall, but linking was faster.
If that still holds, enabling ghash seems only useful when iterating, or if you have a good caching mecanism in your build system (which would avoid rebuilding all).

rnk added a comment.Nov 12 2018, 2:43 PM

@rnk Could you possibly post build metrics for Chromium (for the whole build process, compilation and link) with and without ghash?

I think we'll put the complete analysis here: https://crbug.com/904324 You should be able to star the issue with any google account to get updates by mail.

In my early tests, it seemed that on a large project, compilation was a bit slower overall, but linking was faster.
If that still holds, enabling ghash seems only useful when iterating, or if you have a good caching mecanism in your build system (which would avoid rebuilding all).

That sounds right. It effectively moves hashing work from link time to compile time, which you can mitigate by parallelizing the build with lots of cores or a fancy distributed build system. The extra object file size is crummy, though.

rnk added a comment.Nov 15 2018, 4:40 PM

I collected statistics:
https://bugs.chromium.org/p/chromium/issues/detail?id=904324#c4
The summary is that links in Chromium get 32% faster, but object files grow by 7%. There is no compile time impact. Check it out for more details.

This revision was automatically updated to reflect the committed changes.
dmajor added a subscriber: dmajor.Apr 24 2020, 8:04 AM

Should the directions in http://blog.llvm.org/2018/01/improving-link-time-on-windows-with.html be updated with the new flags?