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

Davide Italiano via llvm-dev llvm-dev at lists.llvm.org
Mon Jan 16 13:56:40 PST 2017

On Mon, 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.
> 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.
> 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

My idea was exactly to have the reordering logic living in LLVM rather
than lld, FWIW.

More information about the llvm-dev mailing list