https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81661
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
One possibility is instead of using
may_be_zero ? 0 : niter
as niter for code-generation use
(may_be_zero ? 0 : 1) * niter
This avoids the gimplification issue. We assemble this as
call __addvsi3
movl %eax, %esi
subl %ebp, %esi
cmpl %ebp, %eax
setge %al
movzbl %al, %eax
imull %eax, %esi
so it definitely is ugly (we're lacking any pattern matching on this
turning it back to a COND_EXPR). And of course we're then unconditionally
emitting a possibly trapping expression into the IL.
For the case in question SCEV analysis knows the expression is executed
if the loop is entered (otherwise it would have rewritten it to unsigned
arithmetic). Also the niter expression is usually similar to the
condition operators.
So I think a solution boils down to the consumer doing sth more intelligent
than building a COND_EXPR and later expecting to just code-gen that via
force_gimple_operand. For the vectorizer this could mean a workaround
like storing niter away somewhere and using a new SSA name for the
niter part in the COND_EXPR and making sure to emit the definition for it
in the correct place. Or going the multiplication way suggested above
for maybe trapping niter (note that tree_could_trap_p doesn't work
recursively, the gimplifier has generic_expr_could_trap_p for this).
Which also means a solution could be to simply not vectorize
loops with IV operations that might trap.
