From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <SRS0=t/xr=4D=kernel.crashing.org=segher@sourceware.org>
Received: from gate.crashing.org (gate.crashing.org [63.228.1.57])
	by sourceware.org (Postfix) with ESMTP id 79D00393BA56
	for <gcc@gcc.gnu.org>; Mon,  5 Dec 2022 16:45:08 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 79D00393BA56
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 2B5Gi3I0001418;
	Mon, 5 Dec 2022 10:44:04 -0600
Received: (from segher@localhost)
	by gate.crashing.org (8.14.1/8.14.1/Submit) id 2B5Gi39h001417;
	Mon, 5 Dec 2022 10:44:03 -0600
X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f
Date: Mon, 5 Dec 2022 10:44:02 -0600
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Kewen.Lin" <linkw@linux.ibm.com>, gcc@gcc.gnu.org,
        Richard Biener <richard.guenther@gmail.com>,
        Peter Bergner <bergner@linux.ibm.com>,
        Jeff Law <jlaw@ventanamicro.com>, Jakub Jelinek <jakub@redhat.com>,
        Michael Meissner <meissner@linux.ibm.com>, richard.sandiford@arm.com
Subject: Re: RFC: Make builtin types only valid for some target features
Message-ID: <20221205164402.GW25951@gate.crashing.org>
References: <372da22f-c33a-9484-7f34-24a2a08d90e1@linux.ibm.com> <mpt359u2tnf.fsf@arm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <mpt359u2tnf.fsf@arm.com>
User-Agent: Mutt/1.4.2.3i
X-Spam-Status: No, score=-2.9 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,KAM_MANYTO,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.gcc.gnu.org>

On Mon, Dec 05, 2022 at 07:31:48AM +0000, Richard Sandiford wrote:
> FWIW, the aarch64 fp move patterns emit the error directly.  They then
> expand an integer-mode move, to provide some error recovery.  (The
> alternative would be to make the error fatal.)
> 
> (define_expand "mov<mode>"
>   [(set (match_operand:GPF_TF_F16_MOV 0 "nonimmediate_operand")
> 	(match_operand:GPF_TF_F16_MOV 1 "general_operand"))]
>   ""
>   {
>     if (!TARGET_FLOAT)
>       {
> 	aarch64_err_no_fpadvsimd (<MODE>mode);
> 	machine_mode intmode
> 	  = int_mode_for_size (GET_MODE_BITSIZE (<MODE>mode), 0).require ();
> 	emit_move_insn (gen_lowpart (intmode, operands[0]),
> 			gen_lowpart (intmode, operands[1]));
> 	DONE;
>       }
> 
> This isn't as user-friendly as catching the error directly in the FE,
> but I think in practice it's going to be very hard to trap all invalid
> uses of a type there.  Also, the user error in these situations is likely
> to be forgetting to enable the right architecture feature, rather than
> accidentally using the wrong type.  So an error about missing architecture
> features is probably good enough in most cases.

The obvious problwem with this is you have to write it separately for
each and every such pattern.  But of course the opaque modes only ever
have mov patterns, everything else goes via builtins, so if this is the
best we can easily do, so be it :-)

Thanks,


Segher