From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 275443858D38 for ; Thu, 22 Sep 2022 21:40:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 275443858D38 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 28MLdPEF019485; Thu, 22 Sep 2022 16:39:25 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 28MLdOGJ019481; Thu, 22 Sep 2022 16:39:24 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 22 Sep 2022 16:39:24 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , David Edelsohn , Peter Bergner Subject: Re: [PATCH] rs6000: Fix condition of define_expand vec_shr_ [PR100645] Message-ID: <20220922213923.GJ25951@gate.crashing.org> References: <354edbb1-e0b0-07b3-ceb7-456442781b0b@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <354edbb1-e0b0-07b3-ceb7-456442781b0b@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_SHORT,SPF_HELO_PASS,SPF_PASS,TXREP 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: Hi! Heh, I first thought I had mistyped thgew PR #, but it is this one after all :-) On Thu, Sep 22, 2022 at 09:41:34AM +0800, Kewen.Lin wrote: > PR100645 exposes one latent bug in define_expand vec_shr_ > that the current condition TARGET_ALTIVEC is too loose. The > mode iterator VEC_L contains a few modes, they are not always > supported as vector mode, VECTOR_UNIT_ALTIVEC_OR_VSX_P should > be used like some other VEC_L usages. > --- a/gcc/config/rs6000/vector.md > +++ b/gcc/config/rs6000/vector.md > @@ -1475,7 +1475,7 @@ (define_expand "vec_shr_" > [(match_operand:VEC_L 0 "vlogical_operand") > (match_operand:VEC_L 1 "vlogical_operand") > (match_operand:QI 2 "reg_or_short_operand")] > - "TARGET_ALTIVEC" > + "VECTOR_UNIT_ALTIVEC_OR_VSX_P (mode)" > --- /dev/null > +++ b/gcc/testsuite/gcc.target/powerpc/pr100645.c > @@ -0,0 +1,13 @@ > +/* { dg-require-effective-target powerpc_altivec_ok } */ > +/* { dg-options "-mdejagnu-cpu=power6 -maltivec" } */ This is a strange choice: we normally do not enable VMX on p6. Just use p7 instead? There is no need for altivec_ok in any case, the -mcpu= guarantees it is satisfied. > +/* It's to verify no ICE here. */ "This used to ICE."? Please commit this now, looks good. Thanks! Segher