From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 86E973856196 for ; Thu, 20 Oct 2022 13:05:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 86E973856196 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 456441FA21; Thu, 20 Oct 2022 13:05:42 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666271142; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4PVAu8WWkgI//H/3NK1rXb6GNJD+N762kKPhOEnPfds=; b=npVa3mghPdU/wdDEi7UmRy5Wu957OWNygkZbpWghIZWjRhe3vmb4OJo3tHYS/2oqn2ha2W smB4x9+rRcVhaSC3lrfZHACDTtti6q6hkWSabrhEj+Jh8lUGxLGGcp3oORzik+UzocUh1g kaOt+9mK84RmGHFk/bzDX9MRd4+sTNA= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666271142; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=4PVAu8WWkgI//H/3NK1rXb6GNJD+N762kKPhOEnPfds=; b=gl2Y9hGYfOT+hGZMuzRzK6y4qjkcST+uf/R+qzLSyE6CP7yu0z7FO2eVfn94Tza2gDr66k DDaLrjqXsKwdopCw== Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 315D013AF5; Thu, 20 Oct 2022 13:05:42 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id SQgCDKZHUWOmOAAAMHmgww (envelope-from ); Thu, 20 Oct 2022 13:05:42 +0000 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Richard Biener Mime-Version: 1.0 (1.0) Subject: Re: [PATCH] match.pd: Fix up gcc.dg/pr54346.c on i686-linux [PR54346] Date: Thu, 20 Oct 2022 15:05:40 +0200 Message-Id: <7DCF8A7B-9BF8-4555-B801-8FDC542A8083@suse.de> References: Cc: gcc-patches@gcc.gnu.org In-Reply-To: To: Jakub Jelinek X-Mailer: iPhone Mail (19H12) X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > Am 20.10.2022 um 14:49 schrieb Jakub Jelinek via Gcc-patches : >=20 > =EF=BB=BFHi! >=20 > The pr54346.c testcase FAILs on i686-linux (without -msse*) for multiple > reasons. One is the trivial missing -Wno-psabi which the following patch > adds, but that isn't enough. The thing is that without native vector > support, we have VEC_PERM_EXPRs in the IL and are actually considering > the nested VEC_PERM_EXPRs into one VEC_PERM_EXPR optimization, but punt > because can_vec_perm_const_p (result_mode, op_mode, sel2, false) is false.= >=20 > Such a test makes sense to prevent "optimizing" two VEC_PERM_EXPRs > that can be handled by the backend natively into one VEC_PERM_EXPR > that can't be handled. But if both of the original VEC_PERM_EXPRs > can't be handled natively either, having just one VEC_PERM_EXPR that will b= e > lowered by generic vec lowering is IMHO still better than 2. > Or even if we trade just one VEC_PERM_EXPR that can't be handled plus > one that can to one that can't be handled. >=20 > Lightly tested so far, ok for trunk if it passes full bootstrap/regtest > on x86_64-linux and i686-linux? Ok Richard=20 > BTW, the testcase also needs to have executable permissions removed... >=20 > 2022-10-20 >=20 > PR tree-optimization/54346 > * match.pd ((vec_perm (vec_perm@0 @1 @2 VECTOR_CST) @0 VECTOR_CST)): > Optimize nested VEC_PERM_EXPRs even if target can't handle the > new one provided we don't increase number of VEC_PERM_EXPRs the > target can't handle. >=20 > * gcc.dg/pr54346.c: Add -Wno-psabi to dg-options. > =20 > --- gcc/match.pd.jj 2022-10-19 11:28:35.111654555 +0200 > +++ gcc/match.pd 2022-10-20 13:45:57.489512189 +0200 > @@ -8118,7 +8118,16 @@ and, > vec_perm_indices sel2 (builder2, 2, nelts); >=20 > tree op0 =3D NULL_TREE; > - if (can_vec_perm_const_p (result_mode, op_mode, sel2, false)) > + /* If the new VEC_PERM_EXPR can't be handled but both > + original VEC_PERM_EXPRs can, punt. > + If one or both of the original VEC_PERM_EXPRs can't be > + handled and the new one can't be either, don't increase > + number of VEC_PERM_EXPRs that can't be handled. */ > + if (can_vec_perm_const_p (result_mode, op_mode, sel2, false) > + || (single_use (@0) > + ? (!can_vec_perm_const_p (result_mode, op_mode, sel0, false) > + || !can_vec_perm_const_p (result_mode, op_mode, sel1, false)) > + : !can_vec_perm_const_p (result_mode, op_mode, sel1, false))) > op0 =3D vec_perm_indices_to_tree (TREE_TYPE (@4), sel2); > } > (if (op0) > --- gcc/testsuite/gcc.dg/pr54346.c.jj 2022-10-11 10:00:07.456124822 +02= 00 > +++ gcc/testsuite/gcc.dg/pr54346.c 2022-10-20 13:46:10.933330119 +0200 > @@ -1,5 +1,5 @@ > /* { dg-do compile } */ > -/* { dg-options "-O -fdump-tree-dse1" } */ > +/* { dg-options "-O -fdump-tree-dse1 -Wno-psabi" } */ >=20 > typedef int veci __attribute__ ((vector_size (4 * sizeof (int)))); >=20 >=20 > Jakub >=20