I've been working on the new LLD COFF linker for 1.5 months so far (including history of my personal repository), and I feel like I should post an update on that matter as a followup to the previous discussion thread. In short, it's doing very well. Completeness It was able to link itself from the first day when the first patch was landed. Since then, I fixed bugs and added more features. It's now able to link everything for check{,-lld,-clang}, and all tests pass. Speed It's generally 2x faster than MSVC linker. It's 10x faster than the old LLD when linking itself. It may be the fastest COFF linker. It's single-threaded. I have a plan to make it even faster by using multiple threads. Simplicity It consists of only 5000 lines of code including comments and blank lines. IMHO the code is simple and easy to read. (This is of course not a third-party opinion, so you are welcomed to read the code. You can skip Windows-specific code to get a whole picture.) Advanced features It supported dead-stripping from day one. I added preliminary ICF (Identical COMDAT Folding) support yesterday. Implementing that was basically just a one day task. Peter Collingbourne (pcc) added an experimental LTO support to the linker. The code for LTO seems to naturally fit to the other pieces of code. Flexibility When I first set the architecture, I was worried that I have made the design too simple, so it could hit a wall at some point as I wrote more code on top of that which prevented us from doing anything beyond that. I'm not too worried about that now -- it looks like my design was a right choice. It's way easier to implement new ideas than before. LTO and ICF are probably good examples. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/1c79e254/attachment.html>
Congratulations! Can we delete the old coff linker? :-) On Jun 24, 2015 4:04 PM, "Rui Ueyama" <ruiu at google.com> wrote:> I've been working on the new LLD COFF linker for 1.5 months so far > (including history of my personal repository), and I feel like I should > post an update on that matter as a followup to the previous discussion > thread. > > In short, it's doing very well. > > Completeness > It was able to link itself from the first day when the first patch was > landed. Since then, I fixed bugs and added more features. It's now able to > link everything for check{,-lld,-clang}, and all tests pass. > > Speed > It's generally 2x faster than MSVC linker. It's 10x faster than the old > LLD when linking itself. It may be the fastest COFF linker. It's > single-threaded. I have a plan to make it even faster by using multiple > threads. > > Simplicity > It consists of only 5000 lines of code including comments and blank lines. > IMHO the code is simple and easy to read. (This is of course not a > third-party opinion, so you are welcomed to read the code. You can skip > Windows-specific code to get a whole picture.) > > Advanced features > It supported dead-stripping from day one. I added preliminary ICF > (Identical COMDAT Folding) support yesterday. Implementing that was > basically just a one day task. Peter Collingbourne (pcc) added an > experimental LTO support to the linker. The code for LTO seems to naturally > fit to the other pieces of code. > > Flexibility > When I first set the architecture, I was worried that I have made the > design too simple, so it could hit a wall at some point as I wrote more > code on top of that which prevented us from doing anything beyond that. I'm > not too worried about that now -- it looks like my design was a right > choice. It's way easier to implement new ideas than before. LTO and ICF are > probably good examples. > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/46f959cd/attachment.html>
Eventually, but not now. I need to support x86 as well as ARM. :) On Wed, Jun 24, 2015 at 3:37 PM, Rafael EspĂndola < rafael.espindola at gmail.com> wrote:> Congratulations! > > Can we delete the old coff linker? :-) > On Jun 24, 2015 4:04 PM, "Rui Ueyama" <ruiu at google.com> wrote: > >> I've been working on the new LLD COFF linker for 1.5 months so far >> (including history of my personal repository), and I feel like I should >> post an update on that matter as a followup to the previous discussion >> thread. >> >> In short, it's doing very well. >> >> Completeness >> It was able to link itself from the first day when the first patch was >> landed. Since then, I fixed bugs and added more features. It's now able to >> link everything for check{,-lld,-clang}, and all tests pass. >> >> Speed >> It's generally 2x faster than MSVC linker. It's 10x faster than the old >> LLD when linking itself. It may be the fastest COFF linker. It's >> single-threaded. I have a plan to make it even faster by using multiple >> threads. >> >> Simplicity >> It consists of only 5000 lines of code including comments and blank >> lines. IMHO the code is simple and easy to read. (This is of course not a >> third-party opinion, so you are welcomed to read the code. You can skip >> Windows-specific code to get a whole picture.) >> >> Advanced features >> It supported dead-stripping from day one. I added preliminary ICF >> (Identical COMDAT Folding) support yesterday. Implementing that was >> basically just a one day task. Peter Collingbourne (pcc) added an >> experimental LTO support to the linker. The code for LTO seems to naturally >> fit to the other pieces of code. >> >> Flexibility >> When I first set the architecture, I was worried that I have made the >> design too simple, so it could hit a wall at some point as I wrote more >> code on top of that which prevented us from doing anything beyond that. I'm >> not too worried about that now -- it looks like my design was a right >> choice. It's way easier to implement new ideas than before. LTO and ICF are >> probably good examples. >> >> _______________________________________________ >> LLVM Developers mailing list >> LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu >> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev >> >>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150624/c80b972b/attachment.html>
Apparently Analagous Threads
- lld-link crash when linking intrinsics lib
- [Release-testers] [6.0.0 Release] Release Candidate 2 tagged
- Proposal for address-significance tables for --icf=safe
- Proposal for address-significance tables for --icf=safe
- Proposal for address-significance tables for --icf=safe