[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

[linkw at gcc dot gnu.org]

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

--- Comment #4 from Kewen Lin <linkw at gcc dot gnu.org> ---
Hi Andre,

Thanks for the detailed explanations all below!

(In reply to avieira from comment #3)
> Hi Kewen,
> 
> Thanks for the analysis. The param_vect_partial_vector_usage suggestion
> seems valid, but that shouldn't be the root cause.
> 
>  I would expect an unpredicated V8HI epilogue to fail for a V8HI main loop
> (unless the main loop was unrolled).
> 
> That is what the following code in vect_analyze_loop_2 is responsible for:
>   /* If we're vectorizing an epilogue loop, the vectorized loop either needs
>      to be able to handle fewer than VF scalars, or needs to have a lower VF
>      than the main loop.  */
>   if (LOOP_VINFO_EPILOGUE_P (loop_vinfo)
>       && !LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P (loop_vinfo)
>       && maybe_ge (LOOP_VINFO_VECT_FACTOR (loop_vinfo),
>                    LOOP_VINFO_VECT_FACTOR (orig_loop_vinfo)))
>     return opt_result::failure_at (vect_location,
>                                    "Vectorization factor too high for"
>                                    " epilogue loop.\n");
> 

For this failure rs6000 specific, this check does take effect, but it's too
late for this case. Since we already decide to re-try vector modes for epilogue
in vect_analyze_loop, the retrying generates one extra unexpected statement in
dumping file. Without the culprit commit, it doesn't have any re-tries.

According to the comments for the snippet with supports_partial_vectors, I
still feel the root cause of this failure is we don't set
supports_partial_vectors right on Power9. Since it's considered as true for
Power9 but actually no as the partial vector capability also respecting
param_vect_partial_vector_usage.

  if (!supports_partial_vectors
           && maybe_ge (GET_MODE_NUNITS (vector_modes[mode_i]),
first_vinfo_vf))

> So PR103997 is looking at fixing the skipping, because we skip too much now.
> You seem to be describing a case where it doesn't skip enough, but like I
> said that should be dealt with the code above, so I have a feeling there may
> be some confusion here.

It seems to me that the case on Power9 even doesn't have a chance to be decided
skipped or not. :)

> 
> I have a patch for the earlier bug at
> https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588330.html 
> This is still under review whils we work out a better way of dealing with
> the issue. Could you maybe check whether that fixes your failures? I'll
> start a cross build for powerpc in the meantime to see if I can check out
> these tests. 
> 

Thanks for the pointer, I just tried the patch and sorry that it didn't help
this failure on rs6000. If my understanding above is correct, it's expected
since the patch being reviewed just touched the code guarded with
!supports_partial_vectors, while this failed case on Power9 doesn't even enter
that block.

> As for why I don't use LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P on the first
> loop vinfo to skip epilogue modes, that's because it is possible to have a
> non-predicated main loop with a predicated epilogue. The test I added for
> aarch64 with that patch is a motivating case.
> 

Thanks for the clarification! On rs6000 it's default with
param_vect_partial_vector_usage 1 that the main loop won't use partial vector
but the epilogue can use, I'd expect the LOOP_VINFO_CAN_USE_PARTIAL_VECTORS_P
of main loop is true if the epilogue can use partial vector. It seems it's
different on aarch64.