Let's have a look at the tree-dump of the existing testcase:
integer(kind=4) runtime_poppar (integer(kind=16) & restrict i)
{
integer(kind=4) res;
{
uint128_t D.4221;
D.4221 = (uint128_t) *i;
res = __builtin_parityll ((unsigned long) D.4221 ^ (unsigned long)
(D.4221 >> 64));
}
return res;
}
My understanding is there is actually nothing left to do,
as the middle-end(?) already handles this.
Am 21.11.21 um 01:22 schrieb Bernhard Reutner-Fischer via Fortran:
Roger pinged this on gcc-patches some time ago fwiw.
[The commit-hooks will likely fix or ignore s/bext/next/ in his
mail-addr]
On Sun, 14 Jun 2020 23:39:32 +0100
"Roger Sayle" <ro...@nextmovesoftware.com> wrote:
The following patch to gfortran's trans-instrinsic.c tweaks the generic that
is produced
for popcnt on integer(kind=16). Currently, the double word popcnt is
implemented as
parityll(hipart(x))^parityll(lopart(x)), but with this patch this is now
translated as
parityll(hipart(x)^lopart(x)). This will be just an aesthetic change once
my tree-level
parity optimization patch of 12th June is reviewed and accepted, but
generating the
more efficient form initially, avoids a tiny bit of garbage collection when
the middle-end
cleans this up into its preferred form. The semantics/correctness of this
change are tested by the run-time tests in gfortran.dg/popcnt_poppar_2.F90
This patch has been tested with "make bootstrap" and "make -k check" on
x86_64-pc-linux-gnu with no regressions. If approved, I'd very much
appreciate it if the (gfortran) reviewer could commit this change for me.
2020-06-14 Roger Sayle <ro...@bextmovesoftware.com>
* trans-intrinsic.c (gfc_conv_intrinsic_popcnt_poppar): Translate
poppar(kind=16) as parityll(hipart(x)^lopart(x)) instead of
parityll(hipart(x))^parityll(lopart(x)).
Thanks in advance,
Roger
--
Roger Sayle
NextMove Software
Cambridge, UK
