From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <segher@kernel.crashing.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
	by sourceware.org (Postfix) with ESMTP id E549C3857B95
	for <gcc-patches@gcc.gnu.org>; Wed, 28 Sep 2022 14:56:24 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E549C3857B95
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 28SEtJU1007838;
	Wed, 28 Sep 2022 09:55:19 -0500
Received: (from segher@localhost)
	by gate.crashing.org (8.14.1/8.14.1/Submit) id 28SEtIfE007837;
	Wed, 28 Sep 2022 09:55:18 -0500
X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f
Date: Wed, 28 Sep 2022 09:55:18 -0500
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Kewen.Lin" <linkw@linux.ibm.com>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>,
        Richard Biener <richard.guenther@gmail.com>,
        David Edelsohn <dje.gcc@gmail.com>,
        Richard Sandiford <richard.sandiford@arm.com>
Subject: Re: [PATCH] rs6000/test: Adjust pr104992.c with vect_int_mod [PR106516]
Message-ID: <20220928145518.GQ25951@gate.crashing.org>
References: <1fb4035e-a15e-5031-3b2f-9ba5dfcb1786@linux.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1fb4035e-a15e-5031-3b2f-9ba5dfcb1786@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,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: <gcc-patches.gcc.gnu.org>

Hi!

On Wed, Aug 24, 2022 at 04:17:55PM +0800, Kewen.Lin wrote:
> As PR106516 shows, we can get unexpected gimple outputs for
> function thud on some target which supports modulus operation
> for vector int.  This patch introduces one effective target
> vect_int_mod for it, then adjusts the test case with it.

> +# Return 1 if the target supports vector int modulus, 0 otherwise.
> +
> +proc check_effective_target_vect_int_mod { } {
> +    return [check_cached_effective_target_indexed vect_int_mod {
> +      expr { [istarget powerpc*-*-*]
> +	     && [check_effective_target_power10_ok] }}]
> +}

power10_ok does not mean the vmod[su][wdq] instructions will be
generated.  You need to test if we have -mcpu=power10 or such, so,
check_effective_target_has_arch_pwr10 .

<X>_ok tests if it is okay to enable <X>.  <X>_hw tests if the hardware
can do <X>.  has_arch_<X> tests if the compiler is asked to generate
code for <X> (which is reflected in the _ARCH_* preprocessor symbols,
hence the name).

Okay for trunk with the correct check_effective_target_* .  Thanks!


Segher