https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #7 from JuzheZhong ---
I don't think this is popcount vectorization issue.
This code should not be vectorized. It's true this code won' be vectorized if
we
use default COST model.
So this is not an issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #6 from Andrew Pinski ---
(In reply to Vineet Gupta from comment #5)
> (In reply to Robin Dapp from comment #4)
>
> > Analyzing loop at pr111791.c:8
> > pr111791.c:8:25: note: === analyze_loop_nest ===
> > pr111791.c:8:25: note:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #5 from Vineet Gupta ---
(In reply to Robin Dapp from comment #4)
> Analyzing loop at pr111791.c:8
> pr111791.c:8:25: note: === analyze_loop_nest ===
> pr111791.c:8:25: note: === vect_analyze_loop_form ===
> pr111791.c:8:25:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #4 from Robin Dapp ---
This is a scalar popcount and as Kito already noted we will just emit
cpop a0, a0
once the zbb extension is present.
As to the question what is actually being vectorized here, I'm not so sure :D
It looks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
JuzheZhong changed:
What|Removed |Added
CC||juzhe.zhong at rivai dot ai
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
--- Comment #2 from Richard Biener ---
It does do that (if there's a POPCOUNT optab, that is). Replacing with
__builtin_popcount would eventually lead to an infinite recursion in this case
;) (see that old memcpy + ldist bug)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111791
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-10-12
CC|
