[llvm-dev] Your help needed: List of LLVM Open Projects 2017
Mehdi Amini via llvm-dev
llvm-dev at lists.llvm.org
Mon Jan 16 14:07:20 PST 2017
> 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.
> -- Sean Silva
> "There are no solved problems; there are only problems that are more
> or less solved" -- Henri Poincare
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev