[LLVMdev] LLD improvement plan

Shankar Easwaran shankare at codeaurora.org
Thu May 7 09:33:18 PDT 2015


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




More information about the llvm-dev mailing list