From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) by sourceware.org (Postfix) with ESMTPS id 42EAB3858C2C for ; Thu, 22 Jun 2023 12:36:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 42EAB3858C2C 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-x22b.google.com with SMTP id 38308e7fff4ca-2b45d7ec066so7480011fa.0 for ; Thu, 22 Jun 2023 05:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1687437398; x=1690029398; 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=K/wR3/mlegP2+HtKtO42vdbO/q3BubRTuLomZupyFWI=; b=Mu2B8+ti4yabWkdT8DCanZ/Yi8ZcHgYM7MUZTPGI8fYcKb1l8SC/lIKEuEub17E/If vaJVn3bWUlPtrP/sVIIUcR1XiLCFnXL3UXdbXXH1/sgVFcEisQMY4u+fJRaQj9KLymt6 2WJ35y7ISGIP5jcuwlC1mVKfFhePsllUWrbHvSbtvzpKLhucETkcIhtM/+Jv3zeIXer/ 1Wpgw4k7v97Mv7Wcv2HXgL/CXOw8+TW580fLgaLR/4kbai8Y0HaCHJ2uoYaIEbSEEXa7 A06zK3+P2QfZWN925Yd1c5S1DNJxVgAm2kON7aeugLwE99l4X/+UV4EmyBdHr1oTDaFa 6Ztw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687437398; x=1690029398; 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=K/wR3/mlegP2+HtKtO42vdbO/q3BubRTuLomZupyFWI=; b=Opml2VEUqaq0Pud/K6eUpUBOK4Mhtkp4G992LQYQJxTyFT75fVGRdSYLCtQTC417vt qHiTRFn3zwpwuXGdKkUbEnb+kFaT71Hsp2SlrrgQixraQPeRq7pXTq/a76faKQ12hMCb WNFoOaxZ3VfHOj2oSXa60QaS4LuJCvA23vyzY1ljNLLv0lvBtAu79pqlhLalOZQs8dvt 9QYCUlN0+SnWp2qNkyGGbQp5JcEGrumT4mQDcItMneDEN3SOBDL24zDTlndpEyw55+RF FbEz9JOXmXRKIDvniZ9qL2zWQ00wpgBLx8cBV3EbK0r0rx+L0wP98mV4B3+WFV5h00lO lQXA== X-Gm-Message-State: AC+VfDymlNjhItJ1y4cM6xv3cmy2NVXOyzsgedH2W0PfJEqrm/9eHOes Q6O6mrfN5JuL7uSUajMeTNGRweLrlciax5PisJo= X-Google-Smtp-Source: ACHHUZ4VcOCYjzcNFjFRHkR/sILBb0bJHkEUTaKgWWplf5rPj86SnVIRWwDvvnIRYrod7VjjJzDSMCtNC5cfYkWG1rs= X-Received: by 2002:a2e:9a96:0:b0:2b4:d416:79eb with SMTP id p22-20020a2e9a96000000b002b4d41679ebmr3363246lji.4.1687437398286; Thu, 22 Jun 2023 05:36:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Richard Biener Date: Thu, 22 Jun 2023 14:33:39 +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=-0.8 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 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 Gcc-pa= tches > > 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_def*) > > > ../../gcc/gcc/tree-ssa-sccvn.cc:7324 > > > 0x120bf4d eliminate_dom_walker::before_dom_children(basic_block_def*) > > > ../../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})&lan= es]; > > > _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 lengths. > > > > > > The attached patch amends the pattern to simplify above VEC_PERM_EXPR > > > only if operand and mask have same number of elements, which seems 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 TREE_= 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_elem_p= ...) OK with that change. 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