Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane

From: Alex Rosenberg <alexr <at> leftfield.org>
Subject: Re: LLD improvement plan
Newsgroups: gmane.comp.compilers.llvm.devel
Date: Sunday 3rd May 2015 20:50:22 UTC (over 3 years ago)
On May 1, 2015, at 7:06 PM, Chandler Carruth  wrote:

> On Fri, May 1, 2015 at 6:46 PM Nick Kledzik  wrote:
> 
> On May 1, 2015, at 12:31 PM, Rui Ueyama  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
 
CD: 3ms