On 8/30/2021 12:51 AM, Richard Biener wrote:
On Fri, Aug 27, 2021 at 9:31 PM Jeff Law via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
I was working some aspects of our port's vector support and stumbled
across a bit of silly code. We were comparing two vectors that were
both uniform.
We can simplify a comparison of uniform vectors to a comparison of a
representative element from each. That in turn may expose const/copy
propagation opportunities or even jump threading opportunities.
And that's precisely what this patch does inside DOM. At the start of
statement processing we see if we can reduce a vector comparison to a
scalar comparison.
You can see this in pr95308.C on x86. As we enter dom3 we have:
;; basic block 2, loop depth 0
;; pred: ENTRY
e.1_1 = e;
_27 = f_26(D) != 0;
_163 = e.1_1 != 0;
_164 = _27 & _163;
_196 = _164 ? -1 : 0;
vect_cst__194 = {_196, _196, _196, _196, _196, _196, _196, _196};
[ ... ]
;; basic block 8, loop depth 1
;; pred: 7
;; 6
if (vect_cst__194 == { 0, 0, 0, 0, 0, 0, 0, 0 })
goto <bb 10>; [100.00%]
else
goto <bb 9>; [20.00%]
;; succ: 10
;; 9
There's another similar comparison later. We transform the comparison into:
;; basic block 8, loop depth 1
;; pred: 7
;; 6
if (_196 == 0)
goto <bb 13>; [100.00%]
else
goto <bb 9>; [20.00%]
;; succ: 13
;; 9
There's nice secondary effects that show up after the transformation as
well.
It's an interesting case indeed, but I think a match.pd rule would have
been better to address this. Sth like
(for cmp (eq ne)
(simplify
(cmp vec_same_elem_p@0 vec_same_elem_p@1)
(if (INTEGRAL_TYPE_P (type)
&& (TREE_CODE (type) == BOOLEAN_TYPE
|| TYPE_PRECISION (type) == 1))
(cmp { uniform_vector_p (@0); } { uniform_vector_p (@1); }))))
should do the trick. That makes the transform available to more places
(and DOM should also pick it up this way).
Good point. I'll give that a whirl.
jeff