similar to: [LLVMdev] LLD improvement plan

Hi, There are a lot of advantages to keep on improving the atom model and working on that model. The atom model allowed lld to have a single intermediate representation for all the formats ELF/COFF/Mach-O. The native model allowed the intermediate representation to be serialized to disk too. If the intermediate representations data structures are made available to scripting languages most

On May 1, 2015, at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > Proposal > Re-architect the linker based on the section model where it’s appropriate. > Stop simulating different linker semantics using the Unix model. Instead, directly implement the native behavior. Preface: I have never personally contributed code to LLD, so don’t take anything I’m about to say too seriously.

I'm sorry if my suggestion gave an impression that I disregard the Mach-O port of the LLD linker. I do care about Mach-O. I do not plan to break or remove any functionality from the current Mach-O port of the LLD. I don't propose to remove the atom model from the linker as long as it seems to be a good fit for the port (and looks like it is). As to the proposal to have two different

On Thu, May 7, 2015 at 12:58 PM, Jim Grosbach <grosbach at apple.com> wrote: > Hi Rui, > > Thank you for clarifying. This is very helpful. > > It’s unfortunate that you’re not seeing benefits from the increased > semantic knowledge the atom based model can provide. I know you’ve explored > the issue thoroughly, though, so I understand why you’re wanting to move a >

I'm sorry for not updating the thread -- I thought I did that before. I started experimenting the idea by implementing a minimal linker using the section-based design with some additional simplification/optimizations. It's already able to link small programs like the LLD itself, and the performance looks indeed better (probably the LLD is too small as a benchmark, but the new one is more

On Mon, May 04, 2015 at 12:52:55PM -0700, Chris Lattner wrote: > I think the problem here is that these lead to natural and inescapable > tensions, and Alex summarized how Camp B has been steering LLD away > from what Camp A people want. This isn’t bad in and of itself, because > what Camp B wants is clearly and unarguably good for LLVM. However, > it is also not sufficient, and

On Tue, Jun 6, 2017 at 11:14 PM, Michael Clark via llvm-dev < llvm-dev at lists.llvm.org> wrote: > OK. I see that the Mach-O linker is not even built when LLD is enabled in > Release_40, only the PE/COFF and ELF linkers are built. > > From looking at reviews it appears that Clang was able to be linked with > LLD on Darwin about 2 years ago, so Mach-O support seems to have

On May 4, 2015, at 1:16 PM, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > It has been said in this thread before, but I fail to see how the atom > model is an actual improvement over the fine grained section model. It > seems to be artifically restricted for no good reasons. Sections come with a huge amount of bloat and overhead that atoms do not. >> Lets stop

On May 28, 2015, at 5:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > I guess, looking back at Nick's comment: > > "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." > > it seems that the primary issue on the

Replying to the thread, not just the email since I was on vacations. First, note that there is a nomenclature issue. A section in ELF/COFF is closer to an atom in MachO than a MachO section IMHO. A rose by any other name would smell as sweet, but sure as hell creates a lot of confusion :-) On 4 May 2015 at 18:05, Chris Lattner <clattner at apple.com> wrote: > On May 4, 2015, at 1:16

On Fri, May 29, 2015 at 6:01 PM, Sean Silva <chisophugis at gmail.com> wrote: > > > On Fri, May 29, 2015 at 1:14 AM, Rui Ueyama <ruiu at google.com> wrote: > >> I want to make it clear that I didn't (at least intend to) compromise >> flexibility or beauty of design with short-term performance gain. I was >> trying to do simple things in a simple way

On Fri, May 29, 2015 at 7:08 PM, Rui Ueyama <ruiu at google.com> wrote: > On Fri, May 29, 2015 at 6:01 PM, Sean Silva <chisophugis at gmail.com> wrote: > >> >> >> On Fri, May 29, 2015 at 1:14 AM, Rui Ueyama <ruiu at google.com> wrote: >> >>> I want to make it clear that I didn't (at least intend to) compromise >>> flexibility

I want to make it clear that I didn't (at least intend to) compromise flexibility or beauty of design with short-term performance gain. I was trying to do simple things in a simple way for both humans and computers, and I believe I did that fairly well. I'd even argue that the new design is cleaner and more expressive than before, because the "atom" model is in some part too

On Fri, May 1, 2015 at 1:32 PM, Michael Spencer <bigcheesegs at gmail.com> wrote: > On Fri, May 1, 2015 at 12:31 PM, Rui Ueyama <ruiu at google.com> wrote: > > Caveat Why not define a section as an atom and keep using the atom > model? If > > we do this, we would have to allow atoms to have more than one name. Each > > name would have an offset in the atom (to

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 >

On Thu, May 28, 2015 at 6:25 PM, Nick Kledzik <kledzik at apple.com> wrote: > > On May 28, 2015, at 5:42 PM, Sean Silva <chisophugis at gmail.com> wrote: > > I guess, looking back at Nick's comment: > > "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.

On Fri, May 29, 2015 at 1:14 AM, Rui Ueyama <ruiu at google.com> wrote: > I want to make it clear that I didn't (at least intend to) compromise > flexibility or beauty of design with short-term performance gain. I was > trying to do simple things in a simple way for both humans and computers, > and I believe I did that fairly well. I'd even argue that the new design

On Mon, May 11, 2015 at 11:13 AM, Rui Ueyama <ruiu at google.com> wrote: > If you attach two ore more symbols along with offsets to a chunk of data, > it would be a pretty similar to a section. That means that if you want to > do something on the atom model, now you have to treat the atoms like > sections. > What do you lose/pay by having to treat the atoms like sections?

On Wed, May 27, 2015 at 9:06 PM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > Replying to the thread, not just the email since I was on vacations. > > First, note that there is a nomenclature issue. A section in ELF/COFF > is closer to an atom in MachO than a MachO section IMHO. > > A rose by any other name would smell as sweet, but sure as hell > creates

Nobody in this long thread appears to have yet explained why it's a bad idea to allow atomic fragments of code/data (whatever you want to call them: atoms, sections, who cares) to have more than one global symbol attached to them in LLD's internal representation. That seems like it'd provide the flexibility needed for ELF without hurting MachO. If that change'd allow you to avoid