[LLVMdev] LLD improvement plan

[Shankar Easwaran]

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