On 5/7/2015 8:38 AM, Joerg Sonnenberger wrote:> On Wed, May 06, 2015 at 09:28:54PM -0500, Shankar Easwaran wrote: >> 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 of all linker script script >> layout can be implemented by the end user. A new language also can >> be developed as most of the users need it and it can work on this >> intermediate representation. >> >> The atom model also simplified a lot of usecases like garbage >> collection and having the resolve to deal just with atoms. The >> section model would sound simple from the outside but it it has its >> own challenges like separating the symbol information from section >> information. > I'm sorry, but I don't get why any of this requires an atom based > representation. Saying that a single intermediate representation for > ELF/COFF on one hand and Mach-O on the other is ironic given the already > mentioned hacks on various layers. Garbage collection doesn't become > more expensive when attaching more than one symbol to each code/data > fragment. Symbol resolution doesn't change when attaching more than one > symbol to each code/data fragment. The list goes on. The single natural > advantage is that you can use a single pointer to the canonical symbol > from a code/data fragment and don't have to use a list/array. Given the > necessary and expensive hacks for splitting sections into (pseudo) > atoms, that doesn't feel like a win. So once again, what actual > advantages for ELF or COFF have been created by the atom model? Mach-O > hardly counts as it doesn't allow the flexibility of the section model > as has been discussed before. >The atom model is optimized when you compile the code with -ffunction-sections and -fdata-sections. Once targets start having -fno-unique-section-names as the default the atom model looks more promising. Everyone likes to have the image size small, and making -ffunction-sections/-fdata-sections (or) -fno-unique-section-names the default make sense and the atom model design directly has a relation to it. In fact it simplifies the linker to not have extra data structures IMO. Shankar Easwaran -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation
On Thu, May 07, 2015 at 10:36:45AM -0500, Shankar Easwaran wrote:> The atom model is optimized when you compile the code with > -ffunction-sections and -fdata-sections....both come with their own price and they don't always generate smaller code.> Once targets start having -fno-unique-section-names as the default > the atom model looks more promising.I don't see how that is related at all.> In fact it simplifies the linker to not have extra > data structures IMO.I'm still waiting for actual examples beyond the trivial difference for the backreference from fragments to symbols. You meanted mergeable string sections in IRC, but that seems actually like a good example *against* the atomic model. Having one atomic per string is quite expensive compared just a section+offset reference with a post-merging update pass. Joerg
On Thu, May 7, 2015 at 8:36 AM, Shankar Easwaran <shankare at codeaurora.org> wrote:> The atom model is optimized when you compile the code with > -ffunction-sections and -fdata-sections. >Not really, -ffunction-sections -fdata-sections gives a section-based linker the same flexibility as an atom-based linker. In the atom model, these extra sections simply serve as a crutch to ensure that object files can be safely atomized. If you commit to the atom model, you shouldn't even need these sections, you should only need a flag that says "this section is safe for atomization". On MachO, this is what .subsections_via_symbols is for.> Once targets start having -fno-unique-section-names as the default the > atom model looks more promising. >Why does LLD care about -fno-unique-section-names? I thought this was just an object file size optimization.> Everyone likes to have the image size small, and making > -ffunction-sections/-fdata-sections (or) -fno-unique-section-names the > default make sense and the atom model design directly has a relation to it. > In fact it simplifies the linker to not have extra data structures IMO.Again, the same is achievable in the section model by turning on these flags and enabling --gc-sections or equivalent functionality. The only advantage I see to using the atom model for ELF and COFF is that we could dead strip object files built without -ffunction-sections -fdata-sections, which would allow us to turn these flags off in the compiler and save on object file size. I suspect the complexity of the atom model isn't worth the file size savings it offers. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150507/522a1cb4/attachment.html>
On 5/7/2015 11:19 AM, Reid Kleckner wrote:> On Thu, May 7, 2015 at 8:36 AM, Shankar Easwaran <shankare at codeaurora.org> > wrote: > >> The atom model is optimized when you compile the code with >> -ffunction-sections and -fdata-sections. >> > Not really, -ffunction-sections -fdata-sections gives a section-based > linker the same flexibility as an atom-based linker. > > In the atom model, these extra sections simply serve as a crutch to ensure > that object files can be safely atomized. If you commit to the atom model, > you shouldn't even need these sections, you should only need a flag that > says "this section is safe for atomization". On MachO, this is what > .subsections_via_symbols is for.We could have this flag on ELF too ? This will reducing code from third party libraries ??> >> Once targets start having -fno-unique-section-names as the default the >> atom model looks more promising. >> > Why does LLD care about -fno-unique-section-names? I thought this was just > an object file size optimization.Sorry I meant -ffunction-sections along with -fno-unique-section-names.> >> Everyone likes to have the image size small, and making >> -ffunction-sections/-fdata-sections (or) -fno-unique-section-names the >> default make sense and the atom model design directly has a relation to it. >> In fact it simplifies the linker to not have extra data structures IMO. > > Again, the same is achievable in the section model by turning on these > flags and enabling --gc-sections or equivalent functionality. > > The only advantage I see to using the atom model for ELF and COFF is that > we could dead strip object files built without -ffunction-sections > -fdata-sections, which would allow us to turn these flags off in the > compiler and save on object file size. I suspect the complexity of the atom > model isn't worth the file size savings it offers. >-- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by the Linux Foundation