[PATCH] gfortran: Improve translation of POPPAR intrinsic
Harald Anlauf
anlauf@gmx.de
Sun Nov 21 18:59:35 GMT 2021
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" <roger@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 <roger@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
>>
>>
>>
>
More information about the Gcc-patches
mailing list