This is an archive of the discontinued LLVM Phabricator instance.

[lld] Merge X86 ELF directories
AbandonedPublic

Authored by garious on Jan 28 2015, 10:06 AM.

Details

Summary

I'm working towards making LLD configurable in the same way LLVM is. Its build iterates over LLVM_TARGETS_TO_BUILD, including only those directories. This patch is the first step in making LLD follow suit. It merges the X86_64 library into the X86 library. No functionality is changed.

Diff Detail

Repository
rL LLVM

Event Timeline

garious updated this revision to Diff 18902.Jan 28 2015, 10:06 AM
garious retitled this revision from to [lld] Merge X86 ELF directories.
garious updated this object.
garious edited the test plan for this revision. (Show Details)
garious set the repository for this revision to rL LLVM.
garious added a project: lld.
garious added a subscriber: Unknown Object (MLST).
shankarke accepted this revision.Jan 28 2015, 10:15 AM
shankarke added a reviewer: shankarke.
This revision is now accepted and ready to land.Jan 28 2015, 10:15 AM
Bigcheese edited edge metadata.Jan 28 2015, 10:39 AM

Do we really need to do this? The build time for each target is tiny, and they don't have dependencies on the llvm targets.

No, we don't have to do this. We don't have to do anything. This is open source!

I believe we'd have an easier time recruiting more target-specific expertise if LLD is rethought as 2 pieces, the LLVM Integrated Linker and a ld-compatible front-end called 'lld'. I'd want to eventually merge both into the LLVM repo. <lld>/tools/lld would sit in <llvm>/tools/lld. <lld>/lib/ReaderWriter/{arch} would be merged into <llvm>/lib/Target/{arch}. After this migration, it'd be natural to add a section for Linker Support to:

http://llvm.org/docs/WritingAnLLVMBackend.html

Imagine the implications of that bit of documentation. Ultimately, I want LLD to follow all the same patterns as the integrated assembler. I believe its success could be partially credited to its tight integration.

-Greg

This is a pretty drastic departure from the original vision for lld. I would rather we discuss this on llvm-dev before pursuing it. Please start a discussion thread there.

emaste added a subscriber: emaste.Jan 29 2015, 5:53 AM

So it doesn't look like there's much interest in moving lld into the llvm repo, but I'd still like to move forward with supporting LLVM_TARGETS_TO_BUILD. Here's what needs to be done:

  1. Land this patch.
  2. Move target-specific code into lib/Target.
  3. Reorg the tests

After this reorg, there would be no separate ELF libs - just Arch libs. We could also move lib/ReaderWriter/ELF up to lib/ELF so that all lld libs are leaves of the directory tree. lld's directory structure seems awkward to me. I usually don't see subdirectories have dependencies on their parent directories - only the other way around.

joerg added a subscriber: joerg.Jan 30 2015, 3:05 PM

I don't see the point in merging 32bit and 64bit x86 backend into one directory. They share very few common properties, i.e. all the relocations are different, the TLS models are different etc.

garious abandoned this revision.Jan 30 2015, 3:33 PM

I think I was only looking at this from the perspective of the build and not from the developer. Since the two targets are conceptually distinct, I don't want to create confusion by merging the directories.

lib/ReaderWriter/ELF/X86_64/X86_64TargetHandler.h