I'd like to request adding polly [1]. polly is a part of the llvm projects. It's their 'Framework for High-Level Loop and Data-Locality Optimizations'. As such, it is quite similar to gcc's Graphite. As it is part of the llvm-project [2], I guess it should be buildable using the llvm.org eclass as well. [1] polly.llvm.org [2] https://github.com/llvm/llvm-project/tree/master/polly
*** Bug 771138 has been marked as a duplicate of this bug. ***
As a playground I modified the LLVM ebuild with an use flag to include polly support. For now, due my limited knowledge about the LLVM build system, it is for the moment built statically. Someone could take a look for building it as a library? I tried to modify distribution_components functions to add it, but somehow its libraries are not installed. Anyway this static version works in my tests and can be a good place to start?
Created attachment 697146 [details] LLVM ebuild LLVM ebuild with static polly support via USE flag
Note that attached ebuild will make polly to work in currently installed Clang but will break every LLVM dependant install due to not installing Polly LLVMPolly and PollyISL libraries
(In reply to David Carlos Manuelda from comment #4) > Note that attached ebuild will make polly to work in currently installed > Clang but will break every LLVM dependant install due to not installing > Polly LLVMPolly and PollyISL libraries Could you please describe the steps to reproduce the problem with your ebuild? I ported your modifications to LLVM 12.0.0, but it seems to work both using Clang and rustc. I will use it for a few more days to see if something comes up.
(In reply to Leonardo Neumann from comment #5) > (In reply to David Carlos Manuelda from comment #4) > > Note that attached ebuild will make polly to work in currently installed > > Clang but will break every LLVM dependant install due to not installing > > Polly LLVMPolly and PollyISL libraries > > Could you please describe the steps to reproduce the problem with your > ebuild? > I ported your modifications to LLVM 12.0.0, but it seems to work both using > Clang and rustc. I will use it for a few more days to see if something comes > up. The ebuild I posted will work, however, once installed/merged, other LLVM dependant software will fail at configure stage due to missing files. To reproduce, install LLVM with this changes and then try to emerge clang, at Cmake's configure stage it will complain about some .a files not installed by the ebuild.
Created attachment 701571 [details] Polly 12.0.0 Well, I managed to get polly as a standalone package and it seems to work fine and pass on all the supported tests. However, it has the drawback that you have to load it as an external optimization pass, which I think that can be solved by properly linking llvm against polly. To build a program using clang with standalone polly, you can do something like this: clang -Xclang -load -Xclang libPolly.so -O2 -mllvm -polly test.c
(In reply to Leonardo Neumann from comment #7) > Created attachment 701571 [details] > Polly 12.0.0 > > Well, I managed to get polly as a standalone package and it seems to work > fine and pass on all the supported tests. However, it has the drawback that > you have to load it as an external optimization pass, which I think that can > be solved by properly linking llvm against polly. To build a program using > clang with standalone polly, you can do something like this: > > clang -Xclang -load -Xclang libPolly.so -O2 -mllvm -polly test.c I also saw that ebuild and tested that way. Unfortunatelly using it this way breaks many packages, specially some autotools based. The best would be to build LLVM with support for it but done in the proper way otherwise the build process would be a nightmare: Build first LLVM+clang Build polly Rebuild LLVM (+clang?) to link against it
I've implemented Polly several months ago without ebuilds modifications.
(In reply to David Carlos Manuelda from comment #8) > Unfortunatelly using it this way breaks many packages, specially some > autotools based. It shouldn't break anything, as long as the user can provide custom compiler flags. But I agree that linking against LLVM should be way more practical and we are not too far from achieving that. (In reply to Perfect Gentleman from comment #9) > I've implemented Polly several months ago without ebuilds modifications. I stumbled upon your implementation, but unfortunately I didn't manage to get the tests running. Does it fix the linking problems with clang and other LLVM-dependent programs?
(In reply to Leonardo Neumann from comment #10) > I stumbled upon your implementation, but unfortunately I didn't manage to > get the tests running. Does it fix the linking problems with clang and other > LLVM-dependent programs? Hmm... It's needed to add some extra LDFLAGS for LLVM staff.
(In reply to Perfect Gentleman from comment #9) > I've implemented Polly several months ago without ebuilds modifications. Hi PG, how can I do this? I'd like to be able to test Polly. Thank you.
(In reply to unhappy-ending from comment #12) > (In reply to Perfect Gentleman from comment #9) > > I've implemented Polly several months ago without ebuilds modifications. > > Hi PG, how can I do this? I'd like to be able to test Polly. Thank you. I think you need to rebuild LLVM adding the Polly libraries -lPolly -lPollyISL in linker. It works up to LLVM 12. In LLVM 13 I'm having linking error because lld is picking the 32-bit library instead of the 64-bit in the 64-bit compile phase, throwing an error of being incompatible with elf64-x86-64 (I've adapted the ebuild to be multilib).
Created attachment 757373 [details] Polly 13.0.0 The linker flags are the only missing thing to get Polly to work without the annoying plugin loading flags. I've been experimenting with Perfect Gentleman's ebuild for a while, and did some slight modifications, as both LLVM_POLLY_LINK_INTO_TOOLS and LLVM_CMAKE_PATH are not required for the ebuild to work. Also, the LDFLAGS are only required on the LLVM package, as both clang and rustc forwards polly optimizations to LLVM. Please test this ebuild and report whether it works for you.
The only step that I think it would be important now is to add a polly useflag into LLVM ebuild so it pulls Polly as a dependency and also adds the required LDFLAGS for it to work.
(In reply to Leonardo Neumann from comment #14) > Created attachment 757373 [details] > Polly 13.0.0 Tried your ebuild, built polly and tried to rebuild llvm --- ld.lld: error: unable to find library -lPolly ld.lld: error: unable to find library -lPollyISL ---
(In reply to Perfect Gentleman from comment #16) > (In reply to Leonardo Neumann from comment #14) > > Created attachment 757373 [details] > > Polly 13.0.0 > > Tried your ebuild, built polly and tried to rebuild llvm > --- > ld.lld: error: unable to find library -lPolly > ld.lld: error: unable to find library -lPollyISL > --- Those libraries should be available under /usr/lib/llvm/13/lib/libPolly{ISL}.a, just like in your ebuild. I only removed LLVM_POLLY_LINK_INTO_TOOLS that should add the LDFLAGS in the LLVM tools if you build both LLVM and Polly together. Can you please check the installation image if these files are available?
(In reply to Leonardo Neumann from comment #17) > Those libraries should be available under > /usr/lib/llvm/13/lib/libPolly{ISL}.a, just like in your ebuild. I only > removed LLVM_POLLY_LINK_INTO_TOOLS that should add the LDFLAGS in the LLVM > tools if you build both LLVM and Polly together. Can you please check the > installation image if these files are available? No, my ebuild installs them into /usr/lib64 ------- /usr/lib64/libPolly.a /usr/lib64/libPollyISL.a -------
(In reply to Perfect Gentleman from comment #18) > (In reply to Leonardo Neumann from comment #17) > > Those libraries should be available under > > /usr/lib/llvm/13/lib/libPolly{ISL}.a, just like in your ebuild. I only > > removed LLVM_POLLY_LINK_INTO_TOOLS that should add the LDFLAGS in the LLVM > > tools if you build both LLVM and Polly together. Can you please check the > > installation image if these files are available? > > No, my ebuild installs them into /usr/lib64 > ------- > /usr/lib64/libPolly.a > /usr/lib64/libPollyISL.a > ------- ebuild for polly-12.0 installed there
Created attachment 861218 [details] Building LLVM Polly 15 without ebuild modification. Removed GPGPU codegen and installation of related libraries.
Created attachment 861219 [details] Building LLVM Polly 16 without ebuild modification
Just add the files I've included to /etc/portage/env/sys-devel/ and you'll be able to build Polly as part of LLVM without having to modify the ebulids.
Why not add support for building Polly along with LLVM via a USE-flag, similar to GCC and Graphite?
Comment on attachment 861219 [details] Building LLVM Polly 16 without ebuild modification >MYCMAKEARGS+='-DLLVM_ENABLE_PROJECTS="polly" ' >MYCMAKEARGS+='-DLLVM_DISTRIBUTION_COMPONENTS=$(printf "%s;%s" $(get_distribution_components) "Polly;LLVMCore;LLVMScalarOpts;LLVMInstCombine;LLVMTransformUtils;LLVMAnalysis;LLVMipo;LLVMMC;LLVMPasses;LLVMLinker;LLVMIRReader;LLVMBitReader;LLVMMCParser;LLVMObject;LLVMProfileData;LLVMTarget;LLVMTargetParser;LLVMVectorize;LLVMBinaryFormat;LLVMRemarks;LLVMAsmParser;LLVMBitstreamReader;LLVMAggressiveInstCombine;LLVMBitWriter;LLVMFrontendOpenMP;LLVMInstrumentation;LLVMBinaryFormat;LLVMDebugInfoCodeView;LLVMTextAPI;LLVMAsmPrinter;LLVMSymbolize;LLVMDebugInfoDWARF;LLVMCodeGen;LLVMCoroutines;LLVMIRPrinter;LLVMObjCARCOpts;LLVMDebugInfoMSF;LLVMDebugInfoPDB;LLVMSelectionDAG;LLVMExtensions;") ' >MYCMAKEARGS+='-DLLVM_TOOL_POLLY_BUILD=ON -DLLVM_POLLY_LINK_INTO_TOOLS=ON ' >LLVM_COMPONENTS=( llvm cmake polly ) > >function post_src_install() { > function polly_install() { > DESTDIR=${D} cmake_build tools/polly/install/strip > } > > multilib_foreach_abi polly_install >}
Comment on attachment 861218 [details] Building LLVM Polly 15 without ebuild modification. Removed GPGPU codegen and installation of related libraries. >MYCMAKEARGS+='-DLLVM_ENABLE_PROJECTS="polly" ' >MYCMAKEARGS+='-DLLVM_DISTRIBUTION_COMPONENTS=$(printf "%s;%s" $(get_distribution_components) "Polly;LLVMCore;LLVMScalarOpts;LLVMInstCombine;LLVMTransformUtils;LLVMAnalysis;LLVMipo;LLVMMC;LLVMPasses;LLVMLinker;LLVMIRReader;LLVMBitReader;LLVMMCParser;LLVMObject;LLVMProfileData;LLVMTarget;LLVMVectorize;LLVMBinaryFormat;LLVMRemarks;LLVMAsmParser;LLVMBitstreamReader;LLVMAggressiveInstCombine;LLVMBitWriter;LLVMFrontendOpenMP;LLVMInstrumentation;LLVMBinaryFormat;LLVMDebugInfoCodeView;LLVMTextAPI;LLVMAsmPrinter;LLVMSymbolize;LLVMDebugInfoDWARF;LLVMCodeGen;LLVMCoroutines;LLVMObjCARCOpts;LLVMDebugInfoMSF;LLVMDebugInfoPDB;LLVMSelectionDAG;LLVMExtensions;") ' >MYCMAKEARGS+='-DLLVM_TOOL_POLLY_BUILD=ON -DLLVM_POLLY_LINK_INTO_TOOLS=ON ' >LLVM_COMPONENTS=( llvm cmake polly third-party ) > >function pre_src_unpack() { > LLVM_COMPONENTS=( llvm cmake polly third-party) > llvm.org_src_unpack >} > >function post_src_install() { > function polly_install() { > DESTDIR=${D} cmake_build tools/polly/install/strip > } > > multilib_foreach_abi polly_install >}
Created attachment 863850 [details] llvm modified ebuild LLVM-15 ebuild modified to enable polly and lto as IUSE
(In reply to Seryoga Leshii from comment #25) > Comment on attachment 861218 [details] > Building LLVM Polly 15 without ebuild modification. Removed GPGPU codegen > and installation of related libraries. > > >MYCMAKEARGS+='-DLLVM_ENABLE_PROJECTS="polly" ' > >MYCMAKEARGS+='-DLLVM_DISTRIBUTION_COMPONENTS=$(printf "%s;%s" $(get_distribution_components) "Polly;LLVMCore;LLVMScalarOpts;LLVMInstCombine;LLVMTransformUtils;LLVMAnalysis;LLVMipo;LLVMMC;LLVMPasses;LLVMLinker;LLVMIRReader;LLVMBitReader;LLVMMCParser;LLVMObject;LLVMProfileData;LLVMTarget;LLVMVectorize;LLVMBinaryFormat;LLVMRemarks;LLVMAsmParser;LLVMBitstreamReader;LLVMAggressiveInstCombine;LLVMBitWriter;LLVMFrontendOpenMP;LLVMInstrumentation;LLVMBinaryFormat;LLVMDebugInfoCodeView;LLVMTextAPI;LLVMAsmPrinter;LLVMSymbolize;LLVMDebugInfoDWARF;LLVMCodeGen;LLVMCoroutines;LLVMObjCARCOpts;LLVMDebugInfoMSF;LLVMDebugInfoPDB;LLVMSelectionDAG;LLVMExtensions;") ' > >MYCMAKEARGS+='-DLLVM_TOOL_POLLY_BUILD=ON -DLLVM_POLLY_LINK_INTO_TOOLS=ON ' > >LLVM_COMPONENTS=( llvm cmake polly third-party ) > > > >function pre_src_unpack() { > > LLVM_COMPONENTS=( llvm cmake polly third-party) > > llvm.org_src_unpack > >} > > > >function post_src_install() { > > function polly_install() { > > DESTDIR=${D} cmake_build tools/polly/install/strip > > } > > > > multilib_foreach_abi polly_install > >} I am creating ebuilds based in your work
Created attachment 863851 [details] llvm:15[polly?,lto?] LLVM:15 ebuild with polly and lto available as IUSE (to mimic gcc with graphite and lto IUSE)
Created attachment 863852 [details] llvm:16[polly?,lto?] llvm:16 polly and lto available as IUSE
Now the problem with my ebuilds is that I can not compile clang with polly enabled. Will investigate further
(In reply to David Carlos Manuelda from comment #30) > Now the problem with my ebuilds is that I can not compile clang with polly > enabled. Will investigate further Fixed as of missing LLVMExtensions in export, will fix the ebuilds now. Instead of "maintainer wanted" can this be addressed by the @llvm herd so it is permanent? since only llvm ebuild needs to be changed.
Created attachment 863857 [details] llvm-15.0.7-r3[polly?,lto?]
Created attachment 863858 [details] llvm-16.0.6[polly?,lto?]
Created attachment 864049 [details] llvm-15.0.7-r3[polly?,lto?] Ebuild cleaned and now use distribution_components to be installed instead of a post_src_install
Created attachment 864050 [details] llvm-16.0.6[polly?,lto?] Ebuild cleaned and now use distribution_components to be installed instead of a post_src_install
There are some strip errors which are non fatal but annoying as they only happen in the newly added files for Polly. Could someone look and try to fix that so the ebuild is as correct as possible? I don't have enough knowledge beyond this point.
Created attachment 864070 [details] llvm-15.0.7-r3[polly?,lto?] Correctly install Polly files
Created attachment 864071 [details] llvm-16.0.6[polly?,lto?] Correctly install Polly files
Dear David! Can You please fix ebuild for LLVM version 17.0.6? I've renamed 16.0.6 but got errors while configured: CMake Error: install(EXPORT "LLVMExports" ...) includes target "LLVMCodeGen" which requires target "LLVMCodeGenTypes" that is not in any export set. CMake Error: install(EXPORT "LLVMExports" ...) includes target "LLVMSelectionDAG" which requires target "LLVMCodeGenTypes" that is not in any export set. CMake Error: install(EXPORT "LLVMExports" ...) includes target "LLVMAsmPrinter" which requires target "LLVMCodeGenTypes" that is not in any export set. CMake Error: install(EXPORT "LLVMExports" ...) includes target "LLVMSymbolize" which requires target "LLVMDebugInfoBTF" that is not in any export set. CMake Error: install(EXPORT "LLVMExports" ...) includes target "LLVMNVPTXCodeGen" which requires target "LLVMCodeGenTypes" that is not in any export set. Thanks!
I might be more practical to switch to the version of LLVM from xarblu's overlay which then links to the Polly package from said overlay if the `polly` USE flag is enabled: https://gpo.zugaina.org/Overlays/xarblu-overlay/sys-devel/polly https://gpo.zugaina.org/Overlays/xarblu-overlay/sys-devel/llvm https://github.com/xarblu/xarblu-overlay Note: As far as I can tell, when Polly is built externally, `-Xclang -load -Xclang libPolly.so` is needed, but I've not needed that with the packages listed above for whatever reason.
(In reply to Sandi (Sandy) Vujaković from comment #40) > I might be more practical to switch to the version of LLVM from xarblu's > overlay which then links to the Polly package from said overlay if the > `polly` USE flag is enabled: > https://gpo.zugaina.org/Overlays/xarblu-overlay/sys-devel/polly > https://gpo.zugaina.org/Overlays/xarblu-overlay/sys-devel/llvm > https://github.com/xarblu/xarblu-overlay > > Note: As far as I can tell, when Polly is built externally, `-Xclang -load > -Xclang libPolly.so` is needed, but I've not needed that with the packages > listed above for whatever reason. This happens when polly and LLVM are compiled in separate stage(packages) then you need to indicate clang to load polly library. In the ebuilds I made, polly is built along with LLVM and LLVM is linked against it so there is no need for extra clang indications (which IMHO is a more correct aproach). I will prepare soon a PR with updated ebuilds (starting from 18+) so they are reviewed and accepted by Gentoo team.
Since I am not the original reported I kindly ask for 2 changes: * Change title to: sys-devel/llvm: Add polyhedral optimizations support (polly IUSE) * Add https://github.com/gentoo/gentoo/pull/36119 PR to "see also" section Hope this can be reviewed and accepted by Gentoo devs.
I'm working on an ebuild too, I took a few whacks and was able to build Polly with LLVM however using it with Clang was not as straight forward as the LLVM docs show: https://polly.llvm.org/docs/UsingPollyWithClang.html You shouldn't have to specify -Xclang -l libPolly.so etc etc Additionally, linking LLVM against a system Polly is not supported upstream, I've seen this method a few times in other ebuilds. For mine, I was going to try building LLVM with Clang, Polly and LLD built-in then specify in RDEPEND, !sys-devel/clang etc That is how LLVM+Clang is recommended to be built by upstream however, this goes against Gentoo guidelines I'm sure. This would mean LLVM would need to be bootstrapped with GCC first, then afterward you'd be able to build LLVM with Clang (the one built into the LLVM package.) Alec
I was able to build LLVM+Polly+Clang and all that's required to call it is: -O3 -mllvm -polly -mllvm -polly-vectorizer=stripmine hello.c And it works, however there is no x86_64-pc-linux-musl-clang executable so trying to build libcxxabi doesn't work.
(In reply to Alec Ari from comment #44) > I was able to build LLVM+Polly+Clang and all that's required to call it is: > > -O3 -mllvm -polly -mllvm -polly-vectorizer=stripmine hello.c > > And it works, however there is no x86_64-pc-linux-musl-clang executable so > trying to build libcxxabi doesn't work. Could you try version 20.0.0.9999 from my PR https://github.com/gentoo/gentoo/pull/36158 on musl?
(In reply to Alec Ari from comment #43) > I'm working on an ebuild too, I took a few whacks and was able to build > Polly with LLVM however using it with Clang was not as straight forward as > the LLVM docs show: > > https://polly.llvm.org/docs/UsingPollyWithClang.html > > You shouldn't have to specify -Xclang -l libPolly.so etc etc > > Additionally, linking LLVM against a system Polly is not supported upstream, > I've seen this method a few times in other ebuilds. > > For mine, I was going to try building LLVM with Clang, Polly and LLD > built-in then specify in RDEPEND, !sys-devel/clang etc > > That is how LLVM+Clang is recommended to be built by upstream however, this > goes against Gentoo guidelines I'm sure. This would mean LLVM would need to > be bootstrapped with GCC first, then afterward you'd be able to build LLVM > with Clang (the one built into the LLVM package.) > > Alec You are right on this, it is against Gentoo guidelines and have been talked in the mentioned PR before. This is why the decision is to build polly separatelly and I hope it can be tested enough and accepted for 19 release soon :)
Alright, so which ebuild should I test? There's this one: https://github.com/StormBytePP/gentoo/blob/884c717fc863530d969632a78b7e9aba5f5453f0/sys-devel/polly/polly-20.0.0.9999.ebuild And this one: https://github.com/xarblu/xarblu-overlay/blob/master/sys-devel/polly/polly-19.1.3.ebuild With those ebuilds, do I ever need to pass things such as: -Xclang -load -Xclang libPolly.so or simply: -mllvm -polly -mllvm -polly-vectorizer=stripmine I'm happy to test, just need to know the best approach.
I'm going to do a fresh Gentoo install and I'll be building my entire system with -O3, LTO and Polly (XFCE, LXQt, Firefox, and a bunch of other things) but I want all my ducks in a row before doing so, making sure I'm trying all the right things and flipping the right switches. I have a 16-thread Ryzen processor so I can just have it build overnight. If you want to make any final changes to the ebuild, now is the time.
Hi, I've tested Polly plugin from xarblu-overlay and pg_overlay, but I'm quite confused whether it's actually doing anything. For example: clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly compiles fine and giving extra bogus -polly-* parameters will complain as expected. But it doesn't seem to actually run any Polly optimization passes with clang/llvm. As described here (https://polly.llvm.org/docs/UsingPollyWithClang.html), I've tried debugging with: clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly -mllvm -polly-dump-before-file=before-polly.ll no before-polly.ll file is written. clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly -mllvm -debug-pass=Arguments 2>&1 | grep -i polly clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly -mllvm -polly-report also nothing is output in either case. Also I've yet to see any differences in binaries with ebuilds compiled with polly enabled in CFLAGS. I've tried with both llvm/clang/polly-18 and llvm/clang/polly-19 Also tried using -Xclang -load -Xclang libPolly.so instead of -fplugin=LLVMPolly.so Adding also -mllvm -polly-parallel -lgomp -mllvm -polly -mllvm -polly-vectorizer=stripmine makes no difference I added some debug fprintfs to the polly code and indeed it seems the plugin is loaded/initialized, but none of the passes seem to get called after that. So what am I missing?
(In reply to Matti Tiainen from comment #49) > Hi, > > I've tested Polly plugin from xarblu-overlay and pg_overlay, but I'm quite > confused whether it's actually doing anything. > > For example: > > clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly > > compiles fine and giving extra bogus -polly-* parameters will complain as > expected. > > But it doesn't seem to actually run any Polly optimization passes with > clang/llvm. > > As described here ([removed because this is a new account), > I've tried debugging with: > > clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly -mllvm > -polly-dump-before-file=before-polly.ll > > no before-polly.ll file is written. > > clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly -mllvm > -debug-pass=Arguments 2>&1 | grep -i polly > clang test.c -c -O3 -fplugin=LLVMPolly.so -mllvm -polly -mllvm -polly-report > > also nothing is output in either case. > > Also I've yet to see any differences in binaries with ebuilds compiled with > polly enabled in CFLAGS. > > I've tried with both llvm/clang/polly-18 and llvm/clang/polly-19 > > Also tried using -Xclang -load -Xclang libPolly.so instead of > -fplugin=LLVMPolly.so > > Adding also -mllvm -polly-parallel -lgomp -mllvm -polly -mllvm > -polly-vectorizer=stripmine makes no difference > > I added some debug fprintfs to the polly code and indeed it seems the plugin > is loaded/initialized, but none of the passes seem to get called after that. > > So what am I missing? Ive used polly on and off for a while now, and for whatever reason, loading the plugin in is... spotty at best. Contrary to current maintainer's hopes, the best way is to currently patchelf clang with libPolly.so, which forces it to be loaded in every time unconditionally
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f7aa346dc0096c8c56c7ec6e8e1f6b7432d6e872 commit f7aa346dc0096c8c56c7ec6e8e1f6b7432d6e872 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-12-26 08:57:28 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2024-12-26 09:15:09 +0000 llvm-core/polly: New live package, 20.0.0.9999 Intended for testing, unclear whether this approach will actually work. Thanks to StormBytePP for the past work. Bug: https://bugs.gentoo.org/715612 See-also: https://github.com/gentoo/gentoo/pull/36158 Signed-off-by: Michał Górny <mgorny@gentoo.org> llvm-core/polly/metadata.xml | 10 ++++++ llvm-core/polly/polly-20.0.0.9999.ebuild | 59 ++++++++++++++++++++++++++++++++ metadata/stabilization-groups/llvm.group | 1 + 3 files changed, 70 insertions(+)
Well, at least some initial testing shows that it's working as expected: (with polybench 4.2.1) $ clang -O3 -Iutilities/ linear-algebra/kernels/doitgen/doitgen.c utilities/polybench.c $ dumbbench ./a.out cmd: Ran 20 iterations (0 outliers). cmd: Rounded run time per iteration (seconds): 4.9641e-01 +/- 3.9e-04 (0.1%) $ clang -O3 -f{pass-,}plugin=LLVMPolly.so -mllvm -polly -Iutilities/ linear-algebra/kernels/doitgen/doitgen.c utilities/polybench.c $ dumbbench ./a.out cmd: Ran 21 iterations (1 outliers). cmd: Rounded run time per iteration (seconds): 1.4063e-01 +/- 3.0e-04 (0.2%) I still need to think how to deal with configuration files -- we'll probably need per-slot configuration file in the end. But when loaded explicitly, it works™.
Looks like -fplugin=LLVMPolly.so is the old way: https://github.com/llvm/llvm-project/issues/88173#issuecomment-2059665029 So -fpass-plugin should be used instead. Is it possible for the ebuild to be tweaked somehow where you don't need to specify -fpass-plugin=LLVMPolly.so ?
We're going to try that in config files, see https://github.com/gentoo/gentoo/pull/39897.
Hi Sam, Thank you, I would recommend deleting -fplugin=LLVMPolly.so from the config file though.
(In reply to Alec Ari from comment #55) > Hi Sam, > > Thank you, I would recommend deleting -fplugin=LLVMPolly.so from the config > file though. Did you test that?
Not yet, just going off the comments from the LLVM issue on Github. He contributes to LLVM and Polly so I think he'd know.
(In reply to Alec Ari from comment #57) > Not yet, just going off the comments from the LLVM issue on Github. He > contributes to LLVM and Polly so I think he'd know. Then I would recommend testing stuff first, prior to assuming I didn't try and making recommendations.
I currently use 18.1.8 Polly from deets-overlay (with a clang patch to find and load it from the 18.1.8 LLVM slot if it's found), and I've collected a list of packages (across my entire desktop system) that does the polly error message spam at some point during compilation. (Surprisingly, it only affects 44 of 1693 packages on a complete system!) I'm willing to share this list, if it helps, so these outliers are known.
(In reply to Neko-san from comment #59) > I currently use 18.1.8 Polly from deets-overlay (with a clang patch to find > and load it from the 18.1.8 LLVM slot if it's found), and I've collected a > list of packages (across my entire desktop system) that does the polly error > message spam at some point during compilation. > (Surprisingly, it only affects 44 of 1693 packages on a complete system!) > > I'm willing to share this list, if it helps, so these outliers are known. I suppose you could tar it up and post it but I think it'd be more relevant if you tested the newly added polly to the gentoo tree and re-gathered the data: https://packages.gentoo.org/packages/llvm-core/polly Just my $0.02
I actually was going to consider that, but the current rebuild requires the version 20 toolchain... and I'm trying to stay on 18 in order to avoid potential build errors from trying to go too bleeding edge. Forgot to mention though, since I didn't count it as part of the number of packages I said earlier: python packages really don't like Polly for some reason - they seem to always error out in the middle. (They also don't like -Wl,-z,defs either)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1d81cec818a31ee21188cf7ea833e2c1cb535a4b commit 1d81cec818a31ee21188cf7ea833e2c1cb535a4b Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2024-12-30 11:44:24 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2025-03-05 13:05:15 +0000 llvm-core/clang-runtime: Add USE=polly Closes: https://bugs.gentoo.org/715612 Signed-off-by: Michał Górny <mgorny@gentoo.org> Closes: https://github.com/gentoo/gentoo/pull/39897 Signed-off-by: Michał Górny <mgorny@gentoo.org> llvm-core/clang-runtime/clang-runtime-21.0.0.9999.ebuild | 13 ++++++++++++- llvm-core/clang-runtime/metadata.xml | 1 + 2 files changed, 13 insertions(+), 1 deletion(-)
That's only for LLVM20 though...
Worse, 21 even, I realize now; why not at least LLVM19?
It's a new feature with breaking changes to Clang. I've backported it to 20.x too, since it's in ~arch. LLVM 19 is EOL.
I didn't realize LLVM19 was EOL already o _ o I only moved to it recently... (I tend to do so slowly to avoid protectional compilation errors) I suppose I should be moving on to newer versions then...?
Yes, LLVM upstream doesn't support anything but what they released last month.
(In reply to Neko-san from comment #66) > I didn't realize LLVM19 was EOL already o _ o Even if it weren't, we're not going to backport new "features" to an older branch. > I only moved to it recently... (I tend to do so slowly to avoid protectional > compilation errors) > > I suppose I should be moving on to newer versions then...? But yes. LLVM only ever supports one branch at a time, and they usually don't even support that branch up until the next release (but discussions are ongoing about improving that, see https://discourse.llvm.org/t/rfc-llvm-lts/84049 and https://discourse.llvm.org/t/rfc-llvm-releases-every-two-weeks/84245). With GCC, 3 branches are supported in addition to trunk/development.
Oh, and I'm going to add USE=polly to 20.x once it is keyworded evrywhere.
Alright, since I said before that I'd share a list of packages Polly has a hard time with, I'm doing it now. Not all of these are ::gentoo packages, but most of them are: ----- dev-libs/libffi dev-lang/luajit dev-libs/angelscript dev-lang/go dev-lang/rust <= Might have a different mechanism to support it, but it fails with the CFLAGS net-misc/croc <= Might have a different mechanism to support it (Go & Rust), but it doesn't fails with the CFLAGS www-client/librewolf <= Might have a different mechanism to support it on the Rust side, but it fails with the CFLAGS app-arch/xz-utils sci-libs/openblas app-arch/zstd media-sound/mpg123-base dev-libs/nspr dev-libs/libsodium dev-libs/wolfssl media-video/v4l2loopback dev-libs/icu dev-libs/nettle dev-libs/openssl dev-libs/randomx dev-libs/supercop dev-python/numpy dev-qt/qtcore media-libs/openal net-libs/gnutls net-libs/libssh net-libs/nodejs sys-apps/rng-tools dev-build/cmake llvm-core/llvm llvm-core/lld llvm-runtimes/libunwind llvm-runtimes/compiler-rt llvm-runtimes/compiler-rt-sanitizers llvm-runtimes/openmp llvm-core/libclc sci-libs/lapack dev-libs/blake3 app-shells/starship net-p2p/monero games-emulation/melonds www-client/ungoogled-chromium games-emulation/cemu sys-apps/mission-center app-text/mupdf media-libs/mesa # Python doesn't like it at all dev-lang/python dev-python/protobuf dev-python/*
This also goes for some ROCm packages, namely the ones that involve hipcc
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=adec6f96d8cc3a08ccef5ca4325ba9ce942b5256 commit adec6f96d8cc3a08ccef5ca4325ba9ce942b5256 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2025-03-23 02:44:32 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2025-03-23 02:44:32 +0000 llvm-core/clang-runtime: Add USE=polly to 20.1.1 Closes: https://bugs.gentoo.org/715612 Signed-off-by: Michał Górny <mgorny@gentoo.org> llvm-core/clang-runtime/clang-runtime-20.1.1.ebuild | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
