[Bug tree-optimization/126053] GCC trunk vs Intel oneAPI : Missed SLP vectorization

[Reshma.Roy at amd dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126053

--- Comment #2 from Reshma Roy <Reshma.Roy at amd dot com> ---
Thank you for the feedback. You are right, I oversimplified it to remove
unrelated code. Even though it's not getting vectorized the reason turns out to
be different from the original case in namd_r. 

In the testcase I passed virial_* and f_i* as reference parameters whereas in
the original they are local variables.

For reference, the actual benchmark function calc_pair_energy_fullelect slp1
dump says:

ComputeNonbondedBase2.h:361:14: missed: failed: evolution of base is not affine
ComputeNonbondedBase2.h:361:14: missed: Cannot determine insertion place for
lane extract
ComputeNonbondedBase2.h:540:18: missed: failed: evolution of base is not affine
ComputeNonbondedBase2.h:540:18: missed: Cannot determine insertion place for
lane extract

So in namd, inside the loop the virials are reduction chains, not stores, and
the only true in-loop memory write is the indirect force update f_j->x -= tmp_x
with f_j = f_1 + pairlisti[k] (ComputeNonbondedBase2.h:361, 540). Also, f_i_x 
is used in a reduction outside the loop f_0[i].x += f_i_x.

I will reiterate and update the testcase mimicking the exact nature as in
namd_r soon.