From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
 id F289738930F8; Tue, 12 Jan 2021 11:49:41 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F289738930F8
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/98550] [11 Regression] ICE in exact_div, at
 poly-int.h:2219 on s390x-linux-gnu
Date: Tue, 12 Jan 2021 11:49:41 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 11.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenth at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 11.0
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: attachments.isobsolete attachments.created
Message-ID: <bug-98550-4-LlJEAq6RSC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-98550-4@http.gcc.gnu.org/bugzilla/>
References: <bug-98550-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-BeenThere: gcc-bugs@gcc.gnu.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Gcc-bugs mailing list <gcc-bugs.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/gcc-bugs>,
 <mailto:gcc-bugs-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Tue, 12 Jan 2021 11:49:42 -0000

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #49948|0                           |1
        is obsolete|                            |

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Created attachment 49951
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=3D49951&action=3Dedit
patch

So while technically correct this interferes with group splitting:

FAIL: gcc.dg/vect/bb-slp-19.c -flto -ffat-lto-objects  scan-tree-dump-times
slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-19.c scan-tree-dump-times slp2 "optimized: basic
block" 1
FAIL: gcc.dg/vect/bb-slp-pr58135.c -flto -ffat-lto-objects=20
scan-tree-dump-times slp2 "optimized: basic block" 1
FAIL: gcc.dg/vect/bb-slp-pr58135.c scan-tree-dump-times slp2 "optimized: ba=
sic
block" 1

bb-slp-19.c has a grouped store of size 9 where we immediately fail due to
the check which is "fatal" as in

      tree nunits_vectype;
      if (!vect_get_vector_types_for_stmt (vinfo, stmt_info, &vectype,
                                           &nunits_vectype, group_size)
          || (nunits_vectype
              && !vect_record_max_nunits (vinfo, stmt_info, group_size,
                                          nunits_vectype, max_nunits)))
        {
          if (is_a <bb_vec_info> (vinfo) && i !=3D 0)
            continue;
          /* Fatal mismatch.  */
          matches[0] =3D false;
          return false;

which means we do not re-try with splitting the store group up.

Now, starting analysis with a group size of 9 is never going to
succeed.  Also note that get_vectype_for_scalar_type mimics the old
test:

  /* If the natural choice of vector type doesn't satisfy GROUP_SIZE,
     try again with an explicit number of elements.  */
  if (vectype
      && group_size
      && maybe_ge (TYPE_VECTOR_SUBPARTS (vectype), group_size))
    {

but the fix must be to how we go discover splitting opportunities I guess.
One option is to only "soft-fail" for max_nunits issues, but then analysis
would still stop at the store (maybe that's even good - who knows, but
how far the match is good is only going to be determined later).=