search for: fastlink

Hi Zach (or anyone else who may have a clue), I'm currently investigating making use of LLVM for PDB parsing for with a view to supporting partial PDBs as produced by /DEBUG:FASTLINK as the VS DIA SDK hasn't been updated to handle them. I know this is probably low on your priority list but since /DEBUG:FASTLINK is now the implied default for VS2017 I figure it's a good time to take a look at it. Unfortunately I'm finding very little information on the internal stru...

...eak 22 // DEBUGGER: r // DEBUGGER: p v // CHECK: ${{[0-9]+}} = // CHECK: Data ={{.*}} 0x0{{(0*)}} // CHECK: Kind = 2142 // win/aggregate-indirect-arg.s // RUN: %clangcl /Z7 %i /c /Fo%t.obj // RUN: %lld-link /DEBUG %t.obj /out:%t.lld.exe // RUN: %run_windbg %t.lld.exe %s // RUN: %ms-link /DEBUG:FASTLINK %t.obj /out:%t.fastlink.exe // RUN: %run_windbg %t.fastlink.exe %s // DEBUGGER: bp 22 // DEBUGGER: g // DEBUGGER: dt v // CHECK: Local var {{.*}} Type SVal // CHECK: +0x000 Data : (null) // CHECK: +0x004 Kind : 0x85e Eventually, some tests will inevitably need to Windows or Posix specific, so you...

...and finished the switch to xxHash64, that saved me around 50 seconds to 56s, then I changed it to uint64_t instead of a 8 byte uint_8 array and that gave me 48s. With release config and a pgo pass I'm now linking in 38s... so faster than link.exe in vs 2017 (which is faster than vs 2015) doing fastlink. Now we are in a very good place, still not as fast as an incremental link, but generating better code and a full pdb. Do you want any of these patches? They don't look the nicest they can be but might help someone doing this cleanly. On Wed, Jan 31, 2018 at 9:39 AM, Leonardo Santagada <s...

I am setting to a shorewall system with 4 NIC''s as per the outline specification below. Can anyone please have a look and let me know what I have missed and what I have got wrong as I want to take this system live ASAP but do not want to kill internet access and the hosting for too long ! I have listed below the system outline & have attached the config files that I have changed, if

You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), but all these per-lib PDBs would have to be merged into a single master PDB at the end, so you still can't avoid that final . In a way, that's similar to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to eliminate the cost of merging types and symbol records) and we know what the problems with /DEBUG:FASTLINK are. The PDB generation code in LLD is still completely single threaded, so that's one area for huge potential gains, but only some parts of the al...

...itch to xxHash64, that > saved me around 50 seconds to 56s, then I changed it to uint64_t > instead of a 8 byte uint_8 array and that gave me 48s. With release > config and a pgo pass I'm now linking in 38s... so faster than > link.exe in vs 2017 (which is faster than vs 2015) doing fastlink. > > Now we are in a very good place, still not as fast as an incremental > link, but generating better code and a full pdb. > > Do you want any of these patches? They don't look the nicest they can > be but might help someone doing this cleanly. > > On Wed, Jan 31, 2018...

...; You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), >>> but all these per-lib PDBs would have to be merged into a single master PDB >>> at the end, so you still can't avoid that final . In a way, that's similar >>> to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to >>> eliminate the cost of merging types and symbol records) and we know what >>> the problems with /DEBUG:FASTLINK are. >>> >>> The PDB generation code in LLD is still completely single threaded, so >>> that's...

...ke a PDB per lib (consider msvcrtd.pdb which ships with >>>> MSVC), but all these per-lib PDBs would have to be merged into a single >>>> master PDB at the end, so you still can't avoid that final . In a way, >>>> that's similar to the idea behind /DEBUG:FASTLINK (keep the debug info in >>>> object files to eliminate the cost of merging types and symbol records) and >>>> we know what the problems with /DEBUG:FASTLINK are. >>>> >>>> The PDB generation code in LLD is still completely single threaded, so >>...

...ogle.com> wrote: > You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), > but all these per-lib PDBs would have to be merged into a single master PDB > at the end, so you still can't avoid that final . In a way, that's similar > to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to > eliminate the cost of merging types and symbol records) and we know what > the problems with /DEBUG:FASTLINK are. > > The PDB generation code in LLD is still completely single threaded, so > that's one area for huge potential gains, but o...

...> >> You can make a PDB per lib (consider msvcrtd.pdb which ships with MSVC), >> but all these per-lib PDBs would have to be merged into a single master PDB >> at the end, so you still can't avoid that final . In a way, that's similar >> to the idea behind /DEBUG:FASTLINK (keep the debug info in object files to >> eliminate the cost of merging types and symbol records) and we know what >> the problems with /DEBUG:FASTLINK are. >> >> The PDB generation code in LLD is still completely single threaded, so >> that's one area for huge po...

..., that >> saved me around 50 seconds to 56s, then I changed it to uint64_t >> instead of a 8 byte uint_8 array and that gave me 48s. With release >> config and a pgo pass I'm now linking in 38s... so faster than >> link.exe in vs 2017 (which is faster than vs 2015) doing fastlink. >> >> Now we are in a very good place, still not as fast as an incremental >> link, but generating better code and a full pdb. >> >> Do you want any of these patches? They don't look the nicest they can >> be but might help someone doing this cleanly. >&g...

That's true, but it still requires the person writing the test to be familiar with both formats. Also anything more trivial than dumping a single local variable will probably run into even more issues. For example, The expression parsers each have their own unique quirks, and it might not always be easy to translate. Besides all the format compatibility issues, there's the more general

...ng again with msvc 2017 I get: >>>>>> >>>>>> lld-link: 4s >>>>>> lld-link /debug: 1m30s and ~20gb of ram >>>>>> lld-link /debug:ghash: 59s and ~20gb of ram >>>>>> link: 13s >>>>>> link /debug:fastlink: 43s and 1gb of ram >>>>>> link specialpdb: 1m10s and 4gb of ram >>>>>> link /debug: 9m16s min and >14gb of ram >>>>>> >>>>>> link incremental: 8s when it works. >>>>>> >>>>>> >>>...

...with msvc 2015, so trying again with msvc 2017 I get: >>>>> >>>>> lld-link: 4s >>>>> lld-link /debug: 1m30s and ~20gb of ram >>>>> lld-link /debug:ghash: 59s and ~20gb of ram >>>>> link: 13s >>>>> link /debug:fastlink: 43s and 1gb of ram >>>>> link specialpdb: 1m10s and 4gb of ram >>>>> link /debug: 9m16s min and >14gb of ram >>>>> >>>>> link incremental: 8s when it works. >>>>> >>>>> >>>>> *specialpdb is...

...; > I cleaned up my tests and figured that the obj file generated with > problems was only with msvc 2015, so trying again with msvc 2017 I get: > > lld-link: 4s > lld-link /debug: 1m30s and ~20gb of ram > lld-link /debug:ghash: 59s and ~20gb of ram > link: 13s > link /debug:fastlink: 43s and 1gb of ram > link specialpdb: 1m10s and 4gb of ram > link /debug: 9m16s min and >14gb of ram > > link incremental: 8s when it works. > > > *specialpdb is created with passing to a set of compilation units (eg a > folder) the same pdb to be written to, so it dedup...

I cleaned up my tests and figured that the obj file generated with problems was only with msvc 2015, so trying again with msvc 2017 I get: lld-link: 4s lld-link /debug: 1m30s and ~20gb of ram lld-link /debug:ghash: 59s and ~20gb of ram link: 13s link /debug:fastlink: 43s and 1gb of ram link specialpdb: 1m10s and 4gb of ram link /debug: 9m16s min and >14gb of ram link incremental: 8s when it works. *specialpdb is created with passing to a set of compilation units (eg a folder) the same pdb to be written to, so it dedups the symbols before the final linkin...

Generally speaking a good rule of thumb is that /debug:ghash will be close to or faster than /debug:fastlink, but with none of the penalties like slow debug time On Sat, Jan 20, 2018 at 12:44 PM Zachary Turner <zturner at google.com> wrote: > Chrome is actually one of my exact benchmark cases. When building > blink_core.dll and browser_tests.exe, i get anywhere from a 20-40% > reduction in...

...and figured that the obj file generated with >> problems was only with msvc 2015, so trying again with msvc 2017 I get: >> >> lld-link: 4s >> lld-link /debug: 1m30s and ~20gb of ram >> lld-link /debug:ghash: 59s and ~20gb of ram >> link: 13s >> link /debug:fastlink: 43s and 1gb of ram >> link specialpdb: 1m10s and 4gb of ram >> link /debug: 9m16s min and >14gb of ram >> >> link incremental: 8s when it works. >> >> >> *specialpdb is created with passing to a set of compilation units (eg a >> folder) the same p...

...opping there is still some more optimizations to get closer to ELF linking times (around 10-15s here). On Sat, Jan 20, 2018 at 9:50 PM, Zachary Turner <zturner at google.com> wrote: > Generally speaking a good rule of thumb is that /debug:ghash will be close > to or faster than /debug:fastlink, but with none of the penalties like slow > debug time > On Sat, Jan 20, 2018 at 12:44 PM Zachary Turner <zturner at google.com> > wrote: > >> Chrome is actually one of my exact benchmark cases. When building >> blink_core.dll and browser_tests.exe, i get anywhere from...

...le generated with >>> problems was only with msvc 2015, so trying again with msvc 2017 I get: >>> >>> lld-link: 4s >>> lld-link /debug: 1m30s and ~20gb of ram >>> lld-link /debug:ghash: 59s and ~20gb of ram >>> link: 13s >>> link /debug:fastlink: 43s and 1gb of ram >>> link specialpdb: 1m10s and 4gb of ram >>> link /debug: 9m16s min and >14gb of ram >>> >>> link incremental: 8s when it works. >>> >>> >>> *specialpdb is created with passing to a set of compilation units (eg a...