[Bug tree-optimization/98854] [11 Regression] cray benchmark is about 15% slower since r11-4428-g4a369d199bf2f34e

["rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
OK, one can see it with BB vectorization enabled vs. disabled.

Bad:

Samples: 7K of event 'cycles:u', Event count (approx.): 7540324763              
Overhead       Samples  Command  Shared Object       Symbol                     
  53.11%          3711  a.out    a.out               [.] shade
  25.39%          1774  a.out    a.out               [.] trace
  18.16%          1271  a.out    a.out               [.] render_scanline
   1.56%           109  a.out    libm-2.26.so        [.] __ieee754_pow_sse2

Good:

Samples: 6K of event 'cycles:u', Event count (approx.): 6673802579              
Overhead       Samples  Command  Shared Object       Symbol                     
  61.21%          3857  a.out    a.out               [.] shade
  20.44%          1288  a.out    a.out               [.] trace
  14.42%           912  a.out    a.out               [.] render_scanline
   1.81%           114  a.out    libm-2.26.so        [.] __ieee754_pow_sse2

With added -fwhole-program we have

c-ray-mt.c:624:18: optimized: basic block part vectorized using 32 byte vectors
c-ray-mt.c:372:13: optimized: basic block part vectorized using 32 byte vectors
c-ray-mt.c:372:13: optimized: basic block part vectorized using 32 byte vectors
c-ray-mt.c:432:9: optimized: basic block part vectorized using 32 byte vectors
c-ray-mt.c:656:7: optimized: basic block part vectorized using 32 byte vectors
c-ray-mt.c:656:7: optimized: basic block part vectorized using 32 byte vectors
c-ray-mt.c:265:23: optimized: basic block part vectorized using 32 byte vectors

:372 is bad and then :656

For the first we vectorize a store

  <bb 26> [local count: 31445960]:
  # nearest_obj_239 = PHI <nearest_obj_11(17), nearest_obj_11(25),
iter_363(24), nearest_obj_11(19), nearest_obj_11(18), iter_363(23)>
...
  _816 = {nearest_sp_pos_x_lsm.258_78, nearest_sp_pos_y_lsm.259_174,
nearest_sp_pos_z_lsm.260_201, nearest_sp_normal_x_lsm.261_200};
  _820 = {nearest_sp_normal_y_lsm.262_122, nearest_sp_normal_z_lsm.263_293,
nearest_sp_vref_x_lsm.264_124, nearest_sp_vref_y_lsm.265_148};
  iter_231 = iter_363->next;
  if (iter_231 != 0B)
    goto <bb 33>; [89.00%]
  else
    goto <bb 27>; [11.00%]

  <bb 33> [local count: 27986904]:
  goto <bb 17>; [100.00%]

  <bb 27> [local count: 3459055]:
  # nearest_sp_dist_lsm.257_228 = PHI <nearest_sp_dist_lsm.257_66(26)>
  # nearest_sp_pos_x_lsm.258_226 = PHI <nearest_sp_pos_x_lsm.258_78(26)>
  # nearest_sp_normal_y_lsm.262_343 = PHI <nearest_sp_normal_y_lsm.262_122(26)>
  # nearest_sp_vref_x_lsm.264_238 = PHI <nearest_sp_vref_x_lsm.264_124(26)>
  # nearest_sp_vref_y_lsm.265_237 = PHI <nearest_sp_vref_y_lsm.265_148(26)>
  # nearest_sp_vref_z_lsm.266_236 = PHI <nearest_sp_vref_z_lsm.266_152(26)>
  # nearest_sp_pos_y_lsm.259_342 = PHI <nearest_sp_pos_y_lsm.259_174(26)>
  # nearest_sp_normal_x_lsm.261_351 = PHI <nearest_sp_normal_x_lsm.261_200(26)>
  # nearest_sp_pos_z_lsm.260_304 = PHI <nearest_sp_pos_z_lsm.260_201(26)>
  # nearest_obj_197 = PHI <nearest_obj_239(26)>
  # nearest_sp_normal_z_lsm.263_821 = PHI <nearest_sp_normal_z_lsm.263_293(26)>
  # vect_nearest_sp_pos_x_lsm.258_226.268_815 = PHI <_816(26)>
  # vect_nearest_sp_pos_x_lsm.258_226.268_814 = PHI <_820(26)>
  nearest_sp.vref.z = nearest_sp_vref_z_lsm.266_236;
  MEM <vector(4) double> [(double *)&nearest_sp] =
vect_nearest_sp_pos_x_lsm.258_226.268_815;
  _812 = &nearest_sp.pos.x + 32;
  MEM <vector(4) double> [(double *)_812] =
vect_nearest_sp_pos_x_lsm.258_226.268_814;

but we insert the vector CTOR on a path that's more often executed than
the use.  And since there's no sinking pass after vectorization nothing
fixes this up.