[Bug bootstrap/97502] New: [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[Bug bootstrap/97502] New: [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[jakub at gcc dot gnu.org]

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

            Bug ID: 97502
           Summary: [11 Regression] PGO bootstrap failure on s390x-linux
                    with -march=z13 starting with r11-3426
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

In profiledbootstrap on s390x-linux --with-arch=z13, I get an ICE during
feedback compilation of s390.c:
/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat-linux/./prev-gcc/xg++
-B/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-
s390x-redhat-linux/./prev-gcc/ -B/usr/s390x-redhat-linux/bin/ -nostdinc++
-B/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat-lin
ux/prev-s390x-redhat-linux/libstdc++-v3/src/.libs
-B/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat-linux/prev-s390x-redhat-lin
ux/libstdc++-v3/libsupc++/.libs 
-I/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat-linux/prev-s390x-redhat-linux/libstdc++-v3/i
nclude/s390x-redhat-linux 
-I/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat-linux/prev-s390x-redhat-linux/libstdc++-v3/include
  -I/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/libstdc++-v3/libsupc++
-L/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat
-linux/prev-s390x-redhat-linux/libstdc++-v3/src/.libs
-L/home/nfs/jakub/rpmbuild/BUILD/gcc-11.0.0-20201019/obj-s390x-redhat-linux/prev-s390x-redhat
-linux/libstdc++-v3/libsupc++/.libs  -fno-PIE -c   -O2 -g -Wall
-Wformat-security -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions
-fstack-protector-strong -
grecord-gcc-switches -march=z13 -mtune=z13 -fasynchronous-unwind-tables
-fstack-clash-protection -fprofile-use -DIN_GCC     -fno-exceptions -fno-rt
ti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute -Woverloaded-
virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings  
-DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../in
clude -I../../gcc/../libcpp/include  -I../../gcc/../libdecnumber
-I../../gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc/../libbacktrace  
-o
 s390.o -MT s390.o -MMD -MP -MF ./.deps/s390.TPo ../../gcc/config/s390/s390.c
...
during RTL pass: expand
../../gcc/config/s390/s390.c: In function 'void s390_register_info()':
../../gcc/config/s390/s390.c:9761:1: internal compiler error: in do_store_flag,
at expr.c:12394
 9761 | s390_register_info ()
      | ^~~~~~~~~~~~~~~~~~
0x163e15d do_store_flag
        ../../gcc/expr.c:12394
0x163e959 expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
        ../../gcc/expr.c:9627
0x16475f9 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
        ../../gcc/expr.c:10171
0x16488b9 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
        ../../gcc/expr.c:8486
0x1756145 expand_normal
        ../../gcc/expr.h:288
0x1756145 expand_vect_cond_optab_fn
        ../../gcc/internal-fn.c:2604
0x1756145 expand_VCONDU
        ../../gcc/internal-fn.def:144
0x14d085b expand_gimple_stmt
        ../../gcc/cfgexpand.c:3851
0x14d085b expand_gimple_basic_block
        ../../gcc/cfgexpand.c:5892
0x14d31ad execute
        ../../gcc/cfgexpand.c:6576
Please submit a full bug report,
with preprocessed source if appropriate.

I've managed to reduce it to a small self-contained testcase that fortunately
doesn't even need PGO:

extern char v[54];
void bar (char *);
void
foo (void)
{
  int i;
  char c[32];
  bar (c);
  for (i = 0; i < 32; i++)
    c[i] = c[i] && !v[i];
  bar (c);
}

ICEs the same way with -O3 -march=z13 starting with
r11-3426-g10843f8303509fcba880c6c05c08e4b4ccd24f36

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |11.0
           Priority|P3                          |P1

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org,
                   |                            |rguenth at gcc dot gnu.org

--- Comment #1 from Martin Liška <marxin at gcc dot gnu.org> ---
Maybe a dup of PR97270?

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the following is problematic:

  vector(16) <signed-boolean:8> _12;
  vector(16) <signed-boolean:8> _14;
  vector(16) <signed-boolean:8> _32;

  _14 = vect__1.7_3 != { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _12 = vect__2.10_15 == { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 };
  _32 = VEC_COND_EXPR <_12, _14, { 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }>;

using a VEC_COND_EXPR to combine two vector bools to another vector bool.
The above could be folded to ~_12 & _14 instead.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |krebbel at gcc dot gnu.org

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
So it looks like vcond_ expand to a vector compare + vsel so it doesn't make
sense that vcond_ accepts cases that vcmp_ expanders reject.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
Or rather, it doesn't make sense to not have vec_cmp[u]{,eq} optabs.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
The vector comparison optabs are:
OPTAB_CD(vec_cmp_optab, "vec_cmp$a$b")
OPTAB_CD(vec_cmpu_optab, "vec_cmpu$a$b")
OPTAB_CD(vec_cmpeq_optab, "vec_cmpeq$a$b")
therefore they need two modes in their names - the first one is the value mode
and the second one is the mask mode.
But then the backend defines named patterns like:
vec_cmpeqv16qi
rather than
vec_cmpeqv16qiv16qi
I'd expect.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
With
--- gcc/config/s390/vx-builtins.md.jj   2020-04-30 09:26:01.000000000 +0200
+++ gcc/config/s390/vx-builtins.md      2020-10-20 16:08:31.847698827 +0200
@@ -812,6 +812,16 @@
   DONE;
 })

+(define_expand "vec_cmp<intcmp:code><VI_HW:mode><VI_HW:mode>"
+  [(set (match_operand:VI_HW               0 "register_operand" "=v")
+       (intcmp:VI_HW (match_operand:VI_HW 1 "register_operand"  "v")
+                     (match_operand:VI_HW 2 "register_operand"  "v")))]
+  "TARGET_VX"
+{
+  s390_expand_vec_compare (operands[0], <intcmp:CODE>, operands[1],
operands[2]);
+  DONE;
+})
+
 (define_expand "vec_cmp<fpcmp:code><mode>"
   [(set (match_operand:<tointvec>              0 "register_operand" "=v")
        (fpcmp:<tointvec> (match_operand:VF_HW 1 "register_operand"  "v")
(couldn't just change the existing pattern easily as s390.c refers to the
current names) the testcase doesn't ICE anymore, but whether it does the right
thing is unclear.  Anyway, deferring to s390x maintainers now.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel <krebbel at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-10-21
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #7 from Andreas Krebbel <krebbel at gcc dot gnu.org> ---
The vec_cmp* expanders in vx-builtins.md are only supposed to be used for
expanding the builtins. Unfortunately the names appear to collide with the rtx
standard names to some degree. I will try to implement the standard name
patterns and direct builtin expansion to them instead.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Andreas Krebbel <krebbel@gcc.gnu.org>:

https://gcc.gnu.org/g:f3cf5174b19a89aeed5aa2ba82a373ded35a4a96

commit r11-4224-gf3cf5174b19a89aeed5aa2ba82a373ded35a4a96
Author: Andreas Krebbel <krebbel@linux.ibm.com>
Date:   Thu Oct 22 12:24:22 2020 +0200

    Fix PR97502

    The S/390 backend does not define vec_cmp expanders so far. We relied
    solely on expanding vcond.  With commit 502d63b6d various testcases
    started to ICE now.

    This patch just adds the missing expanders to prevent the ICE.
    However, there are still a couple of performance-related testcase
    regressions with the vcond lowering which have to be fixed
    independently.

    gcc/ChangeLog:

            PR target/97502
            * config/s390/vector.md ("vec_cmp<VI_HW:mode><VI_HW:mode>")
            ("vec_cmpu<VI_HW:mode><VI_HW:mode>"): New expanders.

    gcc/testsuite/ChangeLog:

            * gcc.dg/pr97502.c: New test.

[Bug bootstrap/97502] [11 Regression] PGO bootstrap failure on s390x-linux with -march=z13 starting with r11-3426

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed.