[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