Davide Italiano via llvm-dev
2017-Jan-16 21:25 UTC
[llvm-dev] Your help needed: List of LLVM Open Projects 2017
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. -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare
Sean Silva via llvm-dev
2017-Jan-16 21:47 UTC
[llvm-dev] Your help needed: List of LLVM Open Projects 2017
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 -- 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/b2aa972c/attachment.html>
Davide Italiano via llvm-dev
2017-Jan-16 21:56 UTC
[llvm-dev] Your help needed: List of LLVM Open Projects 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.
Mehdi Amini via llvm-dev
2017-Jan-16 22:07 UTC
[llvm-dev] Your help needed: List of LLVM Open Projects 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. — 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>