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

[Mehdi Amini via llvm-dev]

> 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 <mailto: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 <mailto: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 <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?

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.
 

> 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 <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.

— 
Mehdi


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170116/95c2a21b/attachment.html>