Then how about enable these flags for -O2? I want to hear from other people
cc'ed, and I may be too cautious, but I'd hesitate to define a new ELF
section if there's other mean already available to achieve the same thing.
On Thu, Jul 25, 2013 at 2:12 PM, Shankar Easwaran
<shankare at codeaurora.org>wrote:
> Not all users compile their code with -ffunction-sections and
> -fdata-sections.
>
> This is to handle usecases when libraries use a mix of object files too.
>
>
>
> On 7/25/2013 4:10 PM, Rui Ueyama wrote:
>
>> Is there any reason -ffunction-sections and -fdata-sections
wouldn't work?
>> If it'll work, it may be be better to say "if you want to get
a better
>> linker output use these options", rather than defining new ELF
section.
>>
>>
>> On Thu, Jul 25, 2013 at 2:01 PM, Shankar Easwaran
>> <shankare at codeaurora.org>**wrote:
>>
>> On 7/25/2013 3:56 PM, Rui Ueyama wrote:
>>>
>>> I think I share the goal with you to make the foundation for
better
>>>> dead-strip, so thank you for suggesting. I'm not sure if
marking a
>>>> section
>>>> as a whole as "safe" or "unsafe" is the
best approach, though. Some
>>>> comments.
>>>>
>>>> - If the compiler generated code is always "safe",
and if we can
>>>> distinguish it from hand-written assembly code by checking if
there's a
>>>> gap
>>>> between symbols, can we just assume a section with no gap is
always
>>>> "safe"?
>>>>
>>>> Gaps could just be caused due to alignment, but the code may
be safe,
>>> which the compiler knows very well.
>>>
>>>
>>> - "Safeness" is not an attribute of the section but
of the symbol, I
>>>
>>>> think. The symbol is "safe" if there's no direct
reference to the symbol
>>>> data. All references should go through relocations. A section
may
>>>> contain
>>>> both "safe" and "unsafe" symbols.
>>>>
>>>> Sections contain symbols. In the context of ELF, marking
sections as
>>> safe/not is more desirable because of the switches
(-ffunction-sections
>>> and
>>> -fdata-sections available already).
>>>
>>>
>>> - How about making the compiler to create a new section for
each
>>> "safe"
>>>
>>>> atom, as it does for inline functions?
>>>>
>>>> You already have a switch called -ffunction-sections and
>>> -fdata-sections
>>> to put function and data in seperate sections.
>>>
>>>
>>> On Thu, Jul 25, 2013 at 10:54 AM, Shankar Easwaran
>>>> <shankare at codeaurora.org>****wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>>> Currently lld ties up all atoms in a section for ELF
together. This
>>>>> proposal just breaks it by handling it differently.
>>>>>
>>>>> *This requires **NO ELF ABI changes.
>>>>>
>>>>> **Definitions :-*
>>>>>
>>>>>
>>>>> A section is not considered safe if there is some code that
appears to
>>>>> be
>>>>> present between function boundaries (or) optimizes sections
to place
>>>>> data
>>>>> at the end or beginning of a section (that contains no
symbol).
>>>>>
>>>>> A section is considered safe if symbols contained within
the section
>>>>> have
>>>>> been associated with their appropriate sizes and there is
no data
>>>>> present
>>>>> between function boundaries.
>>>>>
>>>>> Examples of safe sections are, code generated by compilers.
>>>>>
>>>>> Examples of unsafe sections are, hand written assembly
code.
>>>>>
>>>>> *Changes Needed :-*
>>>>>
>>>>>
>>>>> The change that I am trying to propose is the compiler
emits a section,
>>>>> called (*.safe_sections) *that contains section indices on
what
>>>>> sections
>>>>>
>>>>> are safe.
>>>>>
>>>>> The section would have a SHF_EXCLUDE flag, to prevent other
linkers
>>>>> from
>>>>> consuming this section and making it to the output file.
>>>>>
>>>>> Data structure for this :-
>>>>>
>>>>> .safe_sections
>>>>> <total size>
>>>>> <section index> <boolean flag -- safe/unsafe>
>>>>> ...
>>>>> ...
>>>>>
>>>>>
>>>>> *Advantages
>>>>> *There are advantages that the atoms within a safe section
could just
>>>>> be
>>>>>
>>>>> allocated in the output file which means better output file
layout, and
>>>>> Better performance!
>>>>>
>>>>> This would also result in more atoms getting gc'ed.
>>>>>
>>>>> a) looking at profile information
>>>>> b) taking a order file
>>>>>
>>>>> *Changes needed in the assembler
>>>>>
>>>>> *a) add an additional flag in the section for people
writing assembly
>>>>>
>>>>> code, to mark a section safe or unsafe.
>>>>> *
>>>>> **Changes needed in lld
>>>>>
>>>>> *a) Read the safe section if its present in the object file
>>>>>
>>>>> b) Tie atoms together within a section if the section is
not safe
>>>>> *
>>>>> *Thanks
>>>>>
>>>>> Shankar Easwaran*
>>>>>
>>>>> *
>>>>>
>>>>> --
>>>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora
Forum,
>>>>> hosted by the Linux Foundation
>>>>>
>>>>>
>>>>>
>>>>> --
>>> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted
>>> by the Linux Foundation
>>>
>>>
>>>
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130725/e7175329/attachment.html>