[LLVMdev] LLD improvement plan

[Alex Rosenberg]

On May 1, 2015, at 7:06 PM, Chandler Carruth <chandlerc at google.com> wrote:

> On Fri, May 1, 2015 at 6:46 PM Nick Kledzik <kledzik at apple.com> wrote:
> 
> On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote:
>> The atom model is not the best model for some architectures
> 
> The atom model is a good fit for the llvm compiler model for all architectures.  There is a one-to-one mapping between llvm::GlobalObject (e.g. function or global variable) and lld:DefinedAtom.
> 
> I'm not sure how that's really relevant.
> 
> On some architectures, the unit at which linking is defined to occur isn't a global object. A classic example of this are architectures that have a hard semantic reliance grouping two symbols together and linking either both or neither of them.
>  
> The problem is the ELF/PECOFF file format.   (Actually mach-o is also section based, but we have refrained from adding complex section-centric features to it, so mapping it to atoms is not too hard).
> 
> I’d rather see our effort put to moving ahead to an llvm based object file format (aka “native” format) which bypasses the impedance mismatch of going through ELF/COFF.
> 
> We still have to be able to (efficiently) link existing ELF and COFF objects though? While I'm actually pretty interested in some better object file format, I also want a better linker for the world we live in today...

For us, this is secondary. A major part of the reason we started lld was to embrace the atom model, that is to bring the linker closer to the compiler. We have a lot of long-term goals that involve altering the traditional compiler/linker flow, with a goal toward actual improvements in developer workflow. Just iterating again on the exact same design we've had since the '70s is not good enough.

The same is true of other legacy we're inheriting like linker scripts. While we want them to work and work efficiently, we should consider them part of necessary legacy to support and not make them fundamental to our internal design. This planning will allow us latitude to make fundamental improvements. We make similar decisions across LLVM all the time, take our attitude toward __builtin_constant_p() or nested functions for example.

We've been at this for several years. We had goals and deadlines that we're not meeting. We've abandoned several significant design points so far because Rui is making progress on PECOFF and jettisons things and we let it slide because of his rapid pace.

Core command line? GONE.
Round-trip testing? GONE.
Native file format? GONE.
And now we're against the Atom model?

I don't want a new linker that just happens to be so mired in the same legacy that we've ended up with nothing but a gratuitous rewrite with a better license.

We want:

* A new clean command line that obviates the need for linker scripts and their incestuous design requirements.
* lld is thoroughly tested, including the efficient new native object file format it provides.
* lld is like the rest of LLVM and can be remixed such that it's built-in to the Clang driver, should we choose to.
* We can have the linker drive compilation such that objects don't leave the disk cache before being consumed by the linker.

Perhaps we should schedule an in-person lld meeting. Almost everybody is in the Bay Area. I'm happy to host if we think this will help.

Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150503/ec079bee/attachment.html>