For posterity: This was discussed briefly on IRC, and Segher approved with some simplifications and a request to implement a fail/retry check.
Thanks, Bill On 11/3/21 10:02 AM, Jonathan Wakely wrote: > On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: Any feedback from POWER > maintainers about this? I'd like to push it soon if there's nothing wrong > with it. With the updated patch attached again this time ... > ZjQcmQRYFpfptBannerStart > This Message Is From an External Sender > This message came from outside your organization. > ZjQcmQRYFpfptBannerEnd > On Wed, 3 Nov 2021 at 15:01, Jonathan Wakely wrote: > > Any feedback from POWER maintainers about this? I'd like to push it soon > if there's nothing wrong with it. > > > With the updated patch attached again this time ... > > > > On Wed, 20 Oct 2021 at 14:00, Jonathan Wakely via Libstdc++ > <libstd...@gcc.gnu.org <mailto:libstdc%2b...@gcc.gnu.org>> wrote: > > On 20/10/21 10:12 +0100, Jonathan Wakely wrote: > >On 19/10/21 17:47 +0100, Jonathan Wakely wrote: > >>The ISA-3.0 instruction set includes DARN ("deliver a random > number") > >>which can be used similar to the existing support for RDRAND and > RDSEED. > >> > >>libstdc++-v3/ChangeLog: > >> > >> * src/c++11/random.cc (USE_DARN): Define. > >> (__ppc_darn): New function to use POWER9 DARN instruction. > >> (Which): Add 'darn' enumerator. > >> (which_source): Check for __ppc_darn. > >> (random_device::_M_init): Support "darn" and "hw" tokens. > >> (random_device::_M_getentropy): Add darn to switch. > >> * testsuite/26_numerics/random/random_device/cons/token.cc: > >> Check "darn" token. > >> * testsuite/26_numerics/random/random_device/entropy.cc: > >> Likewise. > >> > >>Tested powerpc64le-linux (power8 and power9) and x86_64-linux. > >> > >>The new "darn" (power-specific) and "hw" (x86 and power) > >>strings should be documented, but I'll do that if this gets > committed. > >> > >>Most of this patch is just "more of the same", similar to the > existing > >>code for RDRAND and RDSEED on x86, but the parts of the patch I'd > like > >>more eyes on are: > >> > >> > >>+#elif defined __powerpc__ && defined __BUILTIN_CPU_SUPPORTS__ > >>+# define USE_DARN 1 > >>#endif > > > >This means DARN can only be used when __builtin_cpu_supports is > >available, which means glibc 2.23 ... is that acceptable? It means > >RHEL 7 wouldn't be able to use DARN, but RHEL 8 would. > > > >There certainly are POWER9 machines running RHEL 7 and similar > >vintages (the GCC compile farm has one) so if there's another way to > >check for ISA 3.0 then I could use that. > > > >If __POWER9_VECTOR__ is defined when building libstdc++, presumably > >that means the whole library can only be run on POWER9 hardware. So > >would that mean we don't need to check __builtin_cpu_supports("darn") > >when __POWER9_VECTOR__ is defined? Or is it possible to build with > >-mcpu=power8 -mpower9-vector and run it on h/w without the DARN > >instruction? > > > >Also, I forgot to add a configure check that the assembler supports > >darn, which is another prerequisite for using it here. > > > >>@@ -135,6 +137,15 @@ namespace std _GLIBCXX_VISIBILITY(default) > >>#endif > >>#endif > >> > >>+#ifdef USE_DARN > >>+ unsigned int > >>+ __attribute__((target("power9"))) > > > >Oops, that should be "cpu=power9". > > > >With that change it works on a POWER9 machine (9009-42A) with glibc > >2.34 and binutils 2.35. > > > > Here's the updated patch with a configure check for assembler support, > and the target attribute fixed. > > This still requires Glibc 2.23 for __builtin_cpu_supports, which I'm > assuming is acceptable. > > > >
