GCC: vectorization difference between two similar loops

In the first case: the code overwrites the same memory location a[i] in each iteration. This inherently sequentializes the loop as the loop iterations are not independent.
(In reality, only the final iteration is actually needed. So the entire inner loop could be taken out.)

In the second case: GCC recognizes the loop as a reduction operation – for which it has special case handling to vectorize.

Compiler vectorization is often implemented as some sort of “pattern matching”. Meaning the compiler analyzes code to see if it fits a certain pattern that it’s able to vectorize. If it does, it gets vectorized. If it doesn’t, then it doesn’t.

This seems to be a corner case where the first loop doesn’t fit any of the pre-coded patterns that GCC can handle. But the second case fits the “vectorizable reduction” pattern.

Here’s the relevant part of GCC’s source code that spits out that "not vectorized: live stmt not supported: " message:

http://svn.open64.net/svnroot/open64/trunk/osprey-gcc-4.2.0/gcc/tree-vect-analyze.c

if (STMT_VINFO_LIVE_P (stmt_info))
{
    ok = vectorizable_reduction (stmt, NULL, NULL);

    if (ok)
        need_to_vectorize = true;
    else
        ok = vectorizable_live_operation (stmt, NULL, NULL);

    if (!ok)
    {
        if (vect_print_dump_info (REPORT_UNVECTORIZED_LOOPS))
        {
            fprintf (vect_dump, 
                "not vectorized: live stmt not supported: ");
            print_generic_expr (vect_dump, stmt, TDF_SLIM);
        }
        return false;
    }
}

From just the line:

vectorizable_reduction (stmt, NULL, NULL);

It’s clear that GCC is checking to see if it matches a “vectorizable reduction” pattern.