pocl builds and runs OK on POWER9 if I patch the ebuild file to remove the X86-only "-DKERNELLIB_HOST_CPU_VARIANTS=distro" CMake flag.
Created attachment 763306 [details, diff]
Patch for pocl ebuild to make flag conditional on ARCH=amd64
The elog message in virtual/opencl should also possibly be altered to mention dev-libs/pocl as an alternative OpenCL implementation.
It also might be worth reconsidering whether "-DKERNELLIB_HOST_CPU_VARIANTS=distro" is needed on amd64 - according to the documentation, this option is supposed to be used when building packages for binary distros that should work on a wide range of CPUs.
(In reply to Chris Kerr from comment #3)
> It also might be worth reconsidering whether
> "-DKERNELLIB_HOST_CPU_VARIANTS=distro" is needed on amd64 - according to the
> documentation, this option is supposed to be used when building packages for
> binary distros that should work on a wide range of CPUs.
The problem is, as mentioned in https://gitweb.gentoo.org/repo/gentoo.git/commit/dev-libs/pocl?id=c127713269a116c187d54663e0523b9f79f11886 / bug 829128, baking in assumptions about the host (other than through *FLAGS) is a pain for binpkgs.
(In reply to Sam James from comment #4)
> The problem is, as mentioned in
> pocl?id=c127713269a116c187d54663e0523b9f79f11886 / bug 829128, baking in
> assumptions about the host (other than through *FLAGS) is a pain for binpkgs.
Good point. Is there a USE flag or other setting that would be appropriate here, to mark the resulting build as not suitable for redistribution?
Another option would be to hand-pick a list of architectures for the LLC_HOST_CPU_VARIANTS on ppc64 to replace the "distro" option on amd64, since there are not so many variants out there anyway. What matters for pocl is the vector extensions so we would only need "generic,pwr7,pwr8,pwr9" matching to altivec,vsx1,vsx2,vsx3 (if my quick glance at Wikipedia is correct).
I just remembered about CPU_FLAGS_PPC - would it be OK to determine the CPU variants based on that?
(In reply to Chris Kerr from comment #6)
> I just remembered about CPU_FLAGS_PPC - would it be OK to determine the CPU
> variants based on that?
Yes, that'd be great.
Any chance I could tempt you into cooking up a patch? (ideally for amd64 too)
Created attachment 763875 [details, diff]
New patch using CPU_FLAGS_PPC
Here is a new attempt using CPU_FLAGS_PPC to set the HOST_CPU_VARIANTS configuration setting. It looks rather ugly though, and compiling extra variants doesn't take very long, so maybe a static selection would make more sense.
Created attachment 781085 [details, diff]
Alternative patch choosing a generic set of host_cpu_variants
The extra compile time and disk space required to use a larger set of host_cpu_variants is negligible, so it is probably better to compile all of them unconditionally rather than using the CPU_FLAGS_PPC variable to select the applicable ones.