https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114032
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Indeed, this feels like a bug, though unlikely to actually trigger anything
wrong.
I wouldn't worry that much about ifcvt IL, but about what makes it out of the
vectorizer.
void
foo (unsigned *p)
{
for (int i = 0; i < 1024; ++i)
p[i] = p[i] ? __builtin_clz (p[i]) : 42;
}
void
bar (unsigned *p)
{
for (int i = 0; i < 1024; ++i)
p[i] = p[i] ? __builtin_clz (p[i]) : 32;
}
with -O3 -mavx512{cd,bw,vl,dq} -mlzcnt -mbmi -mbmi2 -fvect-cost-model=unlimited
Before ifcvt we have conditional __builtin_clz in foo and .CLZ (_4, 32); in
bar,
and out of the vectorizer get the same .CLZ (vect__4.10_37, 32); in both cases,
that looks ok. But without the -mlzcnt -mbmi -mbmi2 options, we have
conditional __builtin_clz in both cases, and vectorizer results in .CLZ
(vect__4.10_37) in both cases. We don't have value ranges on vectors though,
so not really sure what could misbehave during the optimizations later on and I
bet all the targets which support vector .CLZ/.CTZ actually have some well
defined value for zero.
Maybe just the backends even for cases like -mlzcnt -mbmi -mbmi2 should
announce C?Z_VALUE_DEFINED_AT_ZERO for vector modes if it supports vector c?z
optabs? even
if it isn't defined for scalar?
