[llvm-dev] Your help needed: List of LLVM Open Projects 2017

[Davide Italiano via llvm-dev]

On Mon, Jan 16, 2017 at 2:07 PM, Mehdi Amini <mehdi.amini at apple.com> wrote:
>
> On Jan 16, 2017, at 1:47 PM, Sean Silva <chisophugis at gmail.com> wrote:
>
>
>
> On Mon, Jan 16, 2017 at 1:25 PM, Davide Italiano <davide at freebsd.org> wrote:
>>
>> On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva via llvm-dev
>> <llvm-dev at lists.llvm.org> wrote:
>> > Do we have any open projects on LLD?
>> >
>> > I know we usually try to avoid any big "projects" and mainly add/fix
>> > things
>> > in response to user needs, but just wondering if somebody has any ideas.
>> >
>>
>> I'm not particularly active in lld anymore, but the last big item I'd
>> like to see implemented is Pettis-Hansen layout.
>> http://perso.ensta-paristech.fr/~bmonsuez/Cours/B6-4/Articles/papers15.pdf
>> (mainly because it improves performances of the final executable).
>> GCC/gold have an implementation of the algorithm that can be used as
>> base. I'll expand if anybody is interested.
>> Side note: I'd like to propose a couple of llvm projects as well, I'll
>> sit down later today and write them.
>
>
>
> I’m not sure, can you confirm that such layout optimization on ELF requires
> -ffunction-sections?
>

For the non-LTO case, I think so.

> Also, for clang on OSX the best layout we could get is to order functions in
> the order in which they get executed at runtime.
>

That's what we already do for lld. We collect and order file (run a
profiler) and pass that to the linker that lays out functions
accordingly.
This is to improve startup time for a class of startup-time-sensitive
operations. The algorithm proposed by Pettis (allegedly) aims to
reduce the TLB misses as it tries to lay out hot functions (or
functions that are likely to  be called together near in the final
binary).

>
> For FullLTO it is conceptually pretty easy to get profile data we need for
> this, but I'm not sure about the ThinLTO case.
>
> Teresa, Mehdi,
>
> Are there any plans (or things already working!) for getting profile data
> from ThinLTO in a format that the linker can use for code layout? I assume
> that profile data is being used already to guide importing, so it may just
> be a matter of siphoning that off.
>
>
> I’m not sure what kind of “profile information” is needed, and what makes it
> easier for MonolithicLTO compared to ThinLTO?
>
> Or maybe that layout code should be inside LLVM; maybe part of the general
> LTO interface? It looks like the current gcc plugin calls back into gcc for
> the actual layout algorithm itself (function call
> find_pettis_hansen_function_layout) rather than the reordering logic living
> in the linker:
> https://android.googlesource.com/toolchain/gcc/+/3f73d6ef90458b45bbbb33ef4c2b174d4662a22d/gcc-4.6/function_reordering_plugin/function_reordering_plugin.c
>
>
> I was thinking about this: could this be done by reorganizing the module
> itself for LTO?
>
> That wouldn’t help non-LTO and ThinLTO though.

This is a dimension that I think can be explored. The fact that it
wouldn't help with other modes of operation is completely orthogonal,
in particular until it's proven that this kind of optimization makes
sense with ThinLTO (and if it doesn't, it can be an optimization ran
only during full LTO).

-- 
Davide

"There are no solved problems; there are only problems that are more
or less solved" -- Henri Poincare