[Bug target/115519] New: s390 fallout from removing vcond{,u,eq} patterns

[Bug target/115519] New: s390 fallout from removing vcond{,u,eq} patterns

[stefansf at gcc dot gnu.org]

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

            Bug ID: 115519
           Summary: s390 fallout from removing vcond{,u,eq} patterns
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: stefansf at gcc dot gnu.org
            Blocks: 114189
  Target Milestone: ---
            Target: s390*-*-*

When applying the patch from PR114189 testing reveals

gcc.target/s390/vector/vcond-shift.c scan-assembler-not vzero\t*
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrab\t%v.?,%v.?,7 6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesraf\t%v.?,%v.?,31
6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrah\t%v.?,%v.?,15
6
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlb\t%v.?,%v.?,7 4
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlf\t%v.?,%v.?,31
4
gcc.target/s390/vector/vcond-shift.c scan-assembler-times vesrlh\t%v.?,%v.?,15
4
gcc.target/s390/zvector/autovec-long-double-signaling-ge.c scan-assembler
\\n\\twfkhexb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-gt.c scan-assembler
\\n\\twfkhxb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-le.c scan-assembler
\\n\\twfkhexb\\t
gcc.target/s390/zvector/autovec-long-double-signaling-lt.c scan-assembler
\\n\\twfkhxb\\t


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
[Bug 114189] Target implements obsolete vcond{,u,eq} expanders

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

[stefansf at gcc dot gnu.org]

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

--- Comment #1 from Stefan Schulze Frielinghaus <stefansf at gcc dot gnu.org> ---
For example, for function vesrlf_ge from vcond-shift.c we do not end up with

vl      %v2,0(%r2),3
vl      %v0,16(%r2),3
lgr     %r1,%r2
vesrlf  %v4,%v2,31
vesrlf  %v6,%v0,31
vst     %v4,0(%r1),3
vst     %v6,16(%r1),3
br      %r14

anymore but

vl      %v0,0(%r2),3
vl      %v4,16(%r2),3
vgmf    %v6,31,31
vzero   %v2
vesraf  %v1,%v0,31
vesraf  %v3,%v4,31
vsel    %v5,%v6,%v2,%v1
vsel    %v7,%v6,%v2,%v3
lgr     %r1,%r2
vst     %v5,0(%r1),3
vst     %v7,16(%r1),3
br      %r14

During a vcond expand we optimized x < 0 ? 1 : 0 into x >> 31 which we fail to
do, now.  Doing it late in combine fails, too, since we never come up with a
combination of insn 7, 8, 9, and 10:

(insn 7 6 8 2 (set (reg:V4SI 69 [ mask__5.8_4 ])
        (ashiftrt:V4SI (reg:V4SI 68 [ MEM <vector(4) int> [(int *)xx_10] ])
            (const_int 31 [0x1f]))) "vcond-shift.c":155:28 905 {*ashrv4si3}
     (expr_list:REG_DEAD (reg:V4SI 68 [ MEM <vector(4) int> [(int *)xx_10] ])
        (nil)))
(insn 8 7 9 2 (set (reg:V4SI 70)
        (const_vector:V4SI [
                (const_int 1 [0x1]) repeated x4
            ])) 410 {movv4si}
     (nil))
(insn 9 8 10 2 (set (reg:V4SI 71)
        (const_vector:V4SI [
                (const_int 0 [0]) repeated x4
            ])) 410 {movv4si}
     (nil))
(insn 10 9 11 2 (set (reg:V4SI 62 [ vect_patt_18.9 ])
        (if_then_else:V4SI (eq (reg:V4SI 69 [ mask__5.8_4 ])
                (const_vector:V4SI [
                        (const_int 0 [0]) repeated x4
                    ]))
            (reg:V4SI 71)
            (reg:V4SI 70))) 1265 {*vec_sel0v4si}
     (expr_list:REG_DEAD (reg:V4SI 69 [ mask__5.8_4 ])
        (expr_list:REG_EQUAL (if_then_else:V4SI (eq (reg:V4SI 69 [ mask__5.8_4
])
                    (const_vector:V4SI [
                            (const_int 0 [0]) repeated x4
                        ]))
                (const_vector:V4SI [
                        (const_int 0 [0]) repeated x4
                    ])
                (const_vector:V4SI [
                        (const_int 1 [0x1]) repeated x4
                    ]))
            (nil))))

So maybe this is something for match.pd?

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

[stefansf at gcc dot gnu.org]

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

--- Comment #2 from Stefan Schulze Frielinghaus <stefansf at gcc dot gnu.org> ---
Just saw on the ML that a match.pd fix already exists
https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655484.html

A quick test shows that this fixes vcond-shift.c where we now emit

  ((int) ((unsigned int) xx >> 31) + xx) >> 1

and previously

  (xx - (xx >> 31)) >> 1

which is basically the same.  We just have to adapt the times for
scan-assembler w.r.t. signed/unsigned shifts:

diff --git a/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
b/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
index a6b4e97aa50..b942f44039d 100644
--- a/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
+++ b/gcc/testsuite/gcc.target/s390/vector/vcond-shift.c
@@ -3,13 +3,13 @@
 /* { dg-do compile { target { s390*-*-* } } } */
 /* { dg-options "-O3 -march=z13 -mzarch" } */

-/* { dg-final { scan-assembler-times "vesraf\t%v.?,%v.?,31" 6 } } */
-/* { dg-final { scan-assembler-times "vesrah\t%v.?,%v.?,15" 6 } } */
-/* { dg-final { scan-assembler-times "vesrab\t%v.?,%v.?,7" 6 } } */
+/* { dg-final { scan-assembler-times "vesraf\t%v.?,%v.?,31" 4 } } */
+/* { dg-final { scan-assembler-times "vesrah\t%v.?,%v.?,15" 4 } } */
+/* { dg-final { scan-assembler-times "vesrab\t%v.?,%v.?,7" 4 } } */
 /* { dg-final { scan-assembler-not "vzero\t*" } } */
-/* { dg-final { scan-assembler-times "vesrlf\t%v.?,%v.?,31" 4 } } */
-/* { dg-final { scan-assembler-times "vesrlh\t%v.?,%v.?,15" 4 } } */
-/* { dg-final { scan-assembler-times "vesrlb\t%v.?,%v.?,7" 4 } } */
+/* { dg-final { scan-assembler-times "vesrlf\t%v.?,%v.?,31" 6 } } */
+/* { dg-final { scan-assembler-times "vesrlh\t%v.?,%v.?,15" 6 } } */
+/* { dg-final { scan-assembler-times "vesrlb\t%v.?,%v.?,7" 6 } } */

 /* Make it expand to two vector operations.  */
 #define ITER(X) (2 * (16 / sizeof (X[1])))

[Bug target/115519] s390 fallout from removing vcond{,u,eq} patterns

[stefansf at gcc dot gnu.org]

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

--- Comment #3 from Stefan Schulze Frielinghaus <stefansf at gcc dot gnu.org> ---
The failing autovec-long-double-signaling-*.c tests stem from the fact that
vcond_mask_mn is not implemented for V1TF which can be easily done by simply
switching to VT mode iterator and extending TOINTVEC/tointvec.