From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id AE9EE3858D20 for ; Fri, 23 Jun 2023 09:28:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org AE9EE3858D20 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x233.google.com with SMTP id 38308e7fff4ca-2b45c289615so7118421fa.1 for ; Fri, 23 Jun 2023 02:28:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687512523; x=1690104523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=ollQwwpXfqJ9NXn6ExbEB0LGxN0/Y5xLOMtAchqwZMM=; b=f6h5xYtsC6RCN2Srb6LPpj2exdF7BL9PgCblD2B3Vp0bkuXzQK0p6UkCS1ZMHCpEg9 GXvAIbkWyIuewkwo6fJusw63B9Q1Nqn0uO1JzedwAXz3wBMkhVEDGS8A5WMEqqoUNHae qIL2clSXy/R4bM32ftwz9ooCNIvKacx1MJX2iHjuWt3TJUTj5ZeQ6+nMHdknAJZHc0gT AA5bdzF6ulA+MECNj3sf6BFivaYI0eZo9RLT/RoUhWSJUh+++eCZpMHVDIdFE86wEgUZ 55mplON9DB6u3FiqzIlZFGXzkJAaBBug+Q3688KKXkO2DrCRzqf4aYOxDDYrtICIL3RH IYog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687512523; x=1690104523; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=ollQwwpXfqJ9NXn6ExbEB0LGxN0/Y5xLOMtAchqwZMM=; b=FZkWhQkcWXurdylXfdorEHgUjc5b5JTGYjSNI2DEYtoWKCl7gn8EP2UqaBHgNzJicX OF0uQ6sVRuu28MxlIirylRzHlGflQOKVHHxPvs2jwNZVQG0UuVLnqHr6CBAzGYjI0DPM 5WkPzGHQ9FtiQtT9WDQC+BIfJupn6i5pAwkYogcMZX8pJjrHyhpqgOr3RvXq3oN8lxnB zr7PzNalr5w+WOURx/LPaKDtS1KsNUAro7VdZRAb4HdlLKEU8M1ypX2TcnAx6ZVOQ+0i HdrhmdWdcrtCHgYb5nYNKiRf4+3Y+HoCkZmlCOHDae/qLxPvq2s6uTayfd058Hg7OYcG TMsA== X-Gm-Message-State: AC+VfDzturpFq11njhZO++QgtpGDc2Mxz5qIi8UhdZqUp0568eAbwTjD cmX45CGeuBvcFMSyDjKB3FvSLq/fVuUZfEf2I6I6RWhO X-Google-Smtp-Source: ACHHUZ7fIWPyCNY3rOslwkYYAKTLBRbPb7JnZ8pvmMJ2CjFbo9iqahXocyPDdQc2zA8L3K+jI0bE5k04MJVKtofne5Y= X-Received: by 2002:a2e:8747:0:b0:2b5:8eae:7848 with SMTP id q7-20020a2e8747000000b002b58eae7848mr3301814ljj.44.1687512522856; Fri, 23 Jun 2023 02:28:42 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Fri, 23 Jun 2023 11:28:30 +0200 Message-ID: Subject: Re: [SVE][match.pd] Fix ICE observed in PR110280 To: Prathamesh Kulkarni Cc: gcc Patches , Richard Sandiford Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE,WEIRD_PORT autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Jun 23, 2023 at 11:09=E2=80=AFAM Prathamesh Kulkarni wrote: > > On Thu, 22 Jun 2023 at 18:06, Richard Biener = wrote: > > > > On Thu, Jun 22, 2023 at 11:08=E2=80=AFAM Prathamesh Kulkarni > > wrote: > > > > > > On Tue, 20 Jun 2023 at 16:47, Richard Biener wrote: > > > > > > > > On Tue, Jun 20, 2023 at 11:56=E2=80=AFAM Prathamesh Kulkarni via Gc= c-patches > > > > wrote: > > > > > > > > > > Hi Richard, > > > > > For the following reduced test-case taken from PR: > > > > > > > > > > #include "arm_sve.h" > > > > > svuint32_t l() { > > > > > alignas(16) const unsigned int lanes[4] =3D {0, 0, 0, 0}; > > > > > return svld1rq_u32(svptrue_b8(), lanes); > > > > > } > > > > > > > > > > compiling with -O3 -mcpu=3Dgeneric+sve results in following ICE: > > > > > during GIMPLE pass: fre > > > > > pr110280.c: In function 'l': > > > > > pr110280.c:5:1: internal compiler error: in eliminate_stmt, at > > > > > tree-ssa-sccvn.cc:6890 > > > > > 5 | } > > > > > | ^ > > > > > 0x865fb1 eliminate_dom_walker::eliminate_stmt(basic_block_def*, > > > > > gimple_stmt_iterator*) > > > > > ../../gcc/gcc/tree-ssa-sccvn.cc:6890 > > > > > 0x120bf4d eliminate_dom_walker::before_dom_children(basic_block_d= ef*) > > > > > ../../gcc/gcc/tree-ssa-sccvn.cc:7324 > > > > > 0x120bf4d eliminate_dom_walker::before_dom_children(basic_block_d= ef*) > > > > > ../../gcc/gcc/tree-ssa-sccvn.cc:7257 > > > > > 0x1aeec77 dom_walker::walk(basic_block_def*) > > > > > ../../gcc/gcc/domwalk.cc:311 > > > > > 0x11fd924 eliminate_with_rpo_vn(bitmap_head*) > > > > > ../../gcc/gcc/tree-ssa-sccvn.cc:7504 > > > > > 0x1214664 do_rpo_vn_1 > > > > > ../../gcc/gcc/tree-ssa-sccvn.cc:8616 > > > > > 0x1215ba5 execute > > > > > ../../gcc/gcc/tree-ssa-sccvn.cc:8702 > > > > > > > > > > cc1 simplifies: > > > > > lanes[0] =3D 0; > > > > > lanes[1] =3D 0; > > > > > lanes[2] =3D 0; > > > > > lanes[3] =3D 0; > > > > > _1 =3D { -1, ... }; > > > > > _7 =3D svld1rq_u32 (_1, &lanes); > > > > > > > > > > to: > > > > > _9 =3D MEM [(unsigned int * {ref-all})= &lanes]; > > > > > _7 =3D VEC_PERM_EXPR <_9, _9, { 0, 1, 2, 3, ... }>; > > > > > > > > > > and then fre1 dump shows: > > > > > Applying pattern match.pd:8675, generic-match-5.cc:9025 > > > > > Match-and-simplified VEC_PERM_EXPR <_9, _9, { 0, 1, 2, 3, ... }> = to { > > > > > 0, 0, 0, 0 } > > > > > RHS VEC_PERM_EXPR <_9, _9, { 0, 1, 2, 3, ... }> simplified to { 0= , 0, 0, 0 } > > > > > > > > > > The issue seems to be with the following pattern: > > > > > (simplify > > > > > (vec_perm vec_same_elem_p@0 @0 @1) > > > > > @0) > > > > > > > > > > which simplifies above VEC_PERM_EXPR to: > > > > > _7 =3D {0, 0, 0, 0} > > > > > which is incorrect since _9 and mask have different vector length= s. > > > > > > > > > > The attached patch amends the pattern to simplify above VEC_PERM_= EXPR > > > > > only if operand and mask have same number of elements, which seem= s to fix > > > > > the issue, and we're left with the following in .optimized dump: > > > > > [local count: 1073741824]: > > > > > _2 =3D VEC_PERM_EXPR <{ 0, 0, 0, 0 }, { 0, 0, 0, 0 }, { 0, 1, 2= , 3, ... }>; > > > > > > > > it would be nice to have this optimized. > > > > > > > > - > > > > (simplify > > > > (vec_perm vec_same_elem_p@0 @0 @1) > > > > - @0) > > > > + (if (known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (@0)), > > > > + TYPE_VECTOR_SUBPARTS (TREE_TYPE (@1)))) > > > > + @0)) > > > > > > > > that looks good I think. Maybe even better use 'type' instead of T= REE_TYPE (@1) > > > > since that's more obviously the return type in which case > > > > > > > > (if (types_match (type, TREE_TYPE (@0)) > > > > > > > > would be more to the point. > > > > > > > > But can't you to simplify this in the !known_eq case do a simple > > > > > > > > { build_vector_from_val (type, the-element); } > > > > > > > > ? The 'vec_same_elem_p' predicate doesn't get you at the element, > > > > > > > > (with { tree el =3D uniform_vector_p (@0); } > > > > (if (el) > > > > { build_vector_from_val (type, el); }))) > > > > > > > > would be the cheapest workaround. > > > Hi Richard, > > > Thanks for the suggestions. Using build_vector_from_val simplifies it= to: > > > [local count: 1073741824]: > > > return { 0, ... }; > > > > > > Patch is bootstrapped+tested on aarch64-linux-gnu, in progress on > > > x86_64-linux-gnu. > > > OK to commit ? > > > > Can you retain the case of matching type? Like > > > > (if (types_match (type, TREE_TYPE (@0)) > > @0 > > (with > > { > > tree elem =3D uniform_vector_p (@0); > > } > > (if (elem) > > { build_vector_from_val (type, elem); })))) > > > > ? Because uniform_vector_p is strictly less powerful than (vec_same_el= em_p ...) > > > > OK with that change. > Thanks, does the attached patch look OK ? OK. > Bootstrapped+tested on aarch64-linux-gnu and x86_64-linux-gnu. > > Thanks, > Prathamesh > > > > Richard. > > > > > > > > > > Thanks, > > > Prathamesh > > > > > > > > > return _2; > > > > > > > > > > code-gen: > > > > > l: > > > > > mov z0.b, #0 > > > > > ret > > > > > > > > > > Patch is bootstrapped+tested on aarch64-linux-gnu. > > > > > OK to commit ? > > > > > > > > > > Thanks, > > > > > Prathamesh