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

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Tamar Christina from comment #7)
> So there are three cases here. These testcases can all be compiled with
> -Ofast -march=armv8-a+sve2.
> 
> I don't think that clang avoided the unrolling, it's just that it just
> didn't vectorize the loops at all.
> GCC also vectorizes the same part using normal linear loads, but we
> vectorized the other loops with SLP=1 lanes.
> So that's a costing issue on our end. The costing falls apart I think
> because it doesn't cost the throughput
> limitations of all LANE=1 instances together. So it doesn't realize it's
> choking the predicate bandwidth.
> 
> However there are a couple of other things to get from this that clang also
> doesn't do.
> All of these are gated on the basic problem though in that we can't build
> the full SLP
> tree because the operations differ between nodes.
> 
> the part of the code that throws off SLP in both compilers is this
> 
>       int m0 = ((i < n) & (r[i] == 0)) ? -1 : 0;
>       int m1 = ((i + 1 < n) & (r[i + 1] == 0)) ? -1 : 0;
>       int m2 = ((i + 2 < n) & (r[i + 2] == 0)) ? -1 : 0;
>       int m3 = ((i + 3 < n) & (r[i + 3] == 0)) ? -1 : 0;
> 
> because m0 does `i < n` whereas the other operations have a +.
> 
> semantically though we can make the SLP tree if we does
> 
>       int m0 = ((i + 0 < n) & (r[i + 0] == 0)) ? -1 : 0;
>       int m1 = ((i + 1 < n) & (r[i + 1] == 0)) ? -1 : 0;
>       int m2 = ((i + 2 < n) & (r[i + 2] == 0)) ? -1 : 0;
>       int m3 = ((i + 3 < n) & (r[i + 3] == 0)) ? -1 : 0;
> 
> which makes the SLP lanes match.  Me and Richi talked about this two
> cauldrons
> ago and going SLP only was partially to try to do this in a way that doesn't
> require as much backtracking.

I think there's another PR for that.  My notes say that this should be
easier when re-doing the loop SLP discovery to be merge-based.  But in
theory some special-cases can be hacked up in the current discovery,
possibly as part of the mangling we do with operand swapping
(it might also conflict with it, if you consider i < i + 1).

Reply via email to