https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113774
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
unsigned long long a[32], b[32], v[32], r[32];
void
foo (unsigned int n)
{
unsigned long long c = 0;
for (unsigned long i = 0; i < n; i += 2)
{
unsigned long j = i + 1;
b[i] = __builtin_addcll (b[i], v[i], c, &c);
b[j] = __builtin_addcll (b[j], v[j], c, &c);
}
b[4] = __builtin_addcll (b[4] & 1, v[4] & 1, c, &c) & 1;
c = 0;
for (unsigned long i = 0; i < n; i += 2)
{
unsigned long j = i + 1;
unsigned long long k = i < 3 ? a[i] : 0;
r[i] = b[i] | __builtin_subcll (k, b[i], c, &c);
unsigned long long l = b[j];
if (j <= 3)
{
if (j == 3)
k = a[3] & 0x7fffffffffffffffULL;
else
k = a[3];
}
else
k = 0;
r[j] = l | __builtin_subcll (k, b[j], c, &c);
}
r[4] = (b[4] | __builtin_subcll (0, b[4] & 1, c, &c)) & 1;
}
might help understand better what bitintlower emits there, except it uses
PARM_DECLs or automatic VAR_DECLs instead of the global ones (except for v) and
n is 4 (I've used function argument only to avoid VRP figuring out earlier that
certain paths are dead) and the var sizes is actually just 4 (for a) or 5 elts.
That said, even _134 in the #c2 testcase at -O2 in the PHI argument is fishy,
but the
point is that bb 6 is really dead but it isn't known to the compiler yet; it is
reached if _49 <= 2 is false, but given that _49 is incremented in increments
of 2 and the array size is 5 maybe PRE knows that _49 then would have to be 4.
bb 6 either jumps directly to bb 10 (if _140 (aka _49 + 1) > 3) or hops through
bb 8 to bb 10.
