From: Robin Dapp <rdapp.gcc@gmail.com>
To: Richard Biener <richard.guenther@gmail.com>
Cc: rdapp.gcc@gmail.com, gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] vect: Add a popcount fallback.
Date: Tue, 8 Aug 2023 13:37:38 +0200 [thread overview]
Message-ID: <86bb6ae6-1eb5-040a-19ef-bab1e1bc6f4e@gmail.com> (raw)
In-Reply-To: <CAFiYyc0eWX9Bg61DB4T00hhYO9r7OhjbWO1F5ga8TmHRgyChbA@mail.gmail.com>
> Well, not sure how VECT_COMPARE_COSTS can help here, we either
> get the pattern or vectorize the original function. There's no special handling
> for popcount in vectorizable_call so all special cases are handled via patterns.
> I was thinking of popcounthi via popcountsi and zero-extend / truncate but
> also popcountdi via popcountsi and reducing even/odd SI results via a plus
> to a single DI result. It might be that targets without DI/TI popcount support
> but SI popcount support might exist and that this might be cheaper than
> the generic open-coded scheme. But of course such target could then
> implement the DImode version with that trick itself.
Ah, then I misunderstood. Yes, that would be a better fallback option.
A thing for my "spare time" pile :)
Btw another thing I noticed:
/* Input and output of .POPCOUNT should be same-precision integer. */
if (TYPE_PRECISION (unprom_diff.type) != TYPE_PRECISION (lhs_type))
return NULL;
This prevents us from vectorizing i.e.
(uint64_t)__builtin_popcount(uint32_t). It appears like an
unnecessary restriction as all types should be able to hold a popcount
result (as long as TYPE_PRECISION > 6) if the result is properly
converted? Maybe it complicates the fallback handling but in general
we should be fine?
> I agree with two cases it isn't too bad, note you probably get away
> with using the full 64bit constant for both 64bit and 32bit, we simply
> truncate it. Note rather than 'ull' we have the HOST_WIDE_INT_UC
> macro which appends the appropriate suffix.
>
> The patch is OK with or without changing this detail.
Thanks, changed to the full constant. Going to push after bootstrap
and testsuite runs.
Regards
Robin
next prev parent reply other threads:[~2023-08-08 11:37 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-08-07 20:20 Robin Dapp
2023-08-08 6:21 ` Richard Biener
2023-08-08 8:55 ` Robin Dapp
2023-08-08 10:02 ` Richard Biener
2023-08-08 11:37 ` Robin Dapp [this message]
2023-08-08 12:49 ` Richard Biener
2023-08-08 13:06 ` Robin Dapp
2023-08-08 13:28 ` Richard Biener
2023-08-09 10:23 ` Robin Dapp
2023-08-09 11:58 ` Richard Biener
2023-08-08 14:14 ` Jeff Law
2023-08-08 14:21 ` Robin Dapp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=86bb6ae6-1eb5-040a-19ef-bab1e1bc6f4e@gmail.com \
--to=rdapp.gcc@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=richard.guenther@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).