[PATCH] D54802: [LLD][COFF] Generate import modules in PDB

Alexandre Ganea via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Nov 28 07:25:53 PST 2018


aganea added a comment.

In D54802#1309791 <https://reviews.llvm.org/D54802#1309791>, @rnk wrote:

> I don't think we intend to support incremental linking, so I'd just fold idata into rdata by default as we do now.


I'd say incremental linking is the only major hurdle for widespread LLD adoption on industrial sites. Like we discussed at the LLVM conf., I agree that EXEs/DLLs shouldn't be incrementally linked. But what about incremental PDB generation?

For our typical gameplay developement loop, for a DLL target, this is what we see currently:

    Input File Reading:          1847 ms (  3.7%)
    Code Layout:                  579 ms (  1.2%)
    PDB Emission (Cumulative):  43468 ms ( 87.8%)
      Add Objects:              33074 ms ( 66.8%)
        Type Merging:           28276 ms ( 57.1%)
        Symbol Merging:          4748 ms (  9.6%)
      TPI Stream Layout:         1487 ms (  3.0%)
      Globals Stream Layout:     1789 ms (  3.6%)
      Commit to Disk:            5981 ms ( 12.1%)
    Commit Output File:          2837 ms (  5.7%)
  -------------------------------------------------
  Total Link Time:              49494 ms (100.0%)

That is for the bigest DLL in the game, and inherently the one that programmers iterate the most on:

  -- DLL: 182 MB
  -- PDB: 930 MB
  -- Merged OBJs: 179 (no GHASH, OBJs are from cl.exe)
  -- Inserted type records: 91,573,186
  -- Final unique type records: 3,578,658 (hash table size: 8,388,608)
  -- TypeTable.RecordStorage: 1,639,715,884 bytes allocated

For the same thing, `link.exe /INCREMENTAL` takes about 3 sec to relink any change. If we could at least do the Type/Symbol passes incrementally, that would be a major win.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54802/new/

https://reviews.llvm.org/D54802





More information about the llvm-commits mailing list