[PATCH][1/2] Fix PR68553

[Alan Lawrence]

On 04/12/15 17:46, Ramana Radhakrishnan wrote:
>
>
> On 04/12/15 16:04, Richard Biener wrote:
>> On December 4, 2015 4:32:33 PM GMT+01:00, Alan Lawrence <alan.lawrence@arm.com> wrote:
>>> On 27/11/15 08:30, Richard Biener wrote:
>>>>
>>>> This is part 1 of a fix for PR68533 which shows that some targets
>>>> cannot can_vec_perm_p on an identity permutation.  I chose to fix
>>>> this in the vectorizer by detecting the identity itself but with
>>>> the current structure of vect_transform_slp_perm_load this is
>>>> somewhat awkward.  Thus the following no-op patch simplifies it
>>>> greatly (from the times it was restricted to do interleaving-kind
>>>> of permutes).  It turned out to not be 100% no-op as we now can
>>>> handle non-adjacent source operands so I split it out from the
>>>> actual fix.
>>>>
>>>> The two adjusted testcases no longer fail to vectorize because
>>>> of "need three vectors" but unadjusted would fail because there
>>>> are simply not enough scalar iterations in the loop.  I adjusted
>>>> that and now we vectorize it just fine (running into PR68559
>>>> which I filed).
>>>>
>>>> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>>>>
>>>> Richard.
>>>>
>>>> 2015-11-27  Richard Biener  <rguenther@suse.de>
>>>>
>>>> 	PR tree-optimization/68553
>>>> 	* tree-vect-slp.c (vect_get_mask_element): Remove.
>>>> 	(vect_transform_slp_perm_load): Implement in a simpler way.
>>>>
>>>> 	* gcc.dg/vect/pr45752.c: Adjust.
>>>> 	* gcc.dg/vect/slp-perm-4.c: Likewise.
>>>
>>> On aarch64 and ARM targets, this causes
>>>
>>> PASS->FAIL: gcc.dg/vect/O3-pr36098.c scan-tree-dump-times vect
>>> "vectorizing
>>> stmts using SLP" 0
>>>
>>> That is, we now vectorize using SLP, when previously we did not.
>>>
>>> On aarch64 (and I expect ARM too), previously we used a VEC_LOAD_LANES,
>>> without
>>> unrolling,
>> but now we unroll * 4, and vectorize using 3 loads and
>>> permutes:
>>
>> Happens on x86_64 as well with at least Sse4.1.  Unfortunately we'll have to start introducing much more fine-grained target-supports for vect_perm to reliably guard all targets.
>
> I don't know enough about SSE4.1 to know whether it's a problem there or not. This is an actual regression on AArch64 and ARM and not just a testism, you now get :
>
> .L5:
>          ldr     q0, [x5, 16]
>          add     x4, x4, 48
>          ldr     q1, [x5, 32]
>          add     w6, w6, 1
>          ldr     q4, [x5, 48]
>          cmp     w3, w6
>          ldr     q2, [x5], 64
>          orr     v3.16b, v0.16b, v0.16b
>          orr     v5.16b, v4.16b, v4.16b
>          orr     v4.16b, v1.16b, v1.16b
>          tbl     v0.16b, {v0.16b - v1.16b}, v6.16b
>          tbl     v2.16b, {v2.16b - v3.16b}, v7.16b
>          tbl     v4.16b, {v4.16b - v5.16b}, v16.16b
>          str     q0, [x4, -32]
>          str     q2, [x4, -48]
>          str     q4, [x4, -16]
>          bhi     .L5
>
> instead of
>
> .L5:
>          ld4     {v4.4s - v7.4s}, [x7], 64
>          add     w4, w4, 1
>          cmp     w3, w4
>          orr     v1.16b, v4.16b, v4.16b
>          orr     v2.16b, v5.16b, v5.16b
>          orr     v3.16b, v6.16b, v6.16b
>          st3     {v1.4s - v3.4s}, [x6], 48
>          bhi     .L5
>
> LD4 and ST3 do all the permutes without needing actual permute instructions - a strategy that favours generic permutes avoiding the load_lanes case is likely to be more expensive on most implementations. I think worth a PR atleast.
>
> regards
> Ramana
>

Yes, quite right. PR 68707.

--Alan