From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 6D780388B6A6 for ; Mon, 5 Dec 2022 07:31:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D780388B6A6 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 9AD7D23A; Sun, 4 Dec 2022 23:31:57 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.62]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id BF3EB3F73D; Sun, 4 Dec 2022 23:31:49 -0800 (PST) From: Richard Sandiford To: "Kewen.Lin" Mail-Followup-To: "Kewen.Lin" ,gcc@gcc.gnu.org, Richard Biener , Segher Boessenkool , Peter Bergner , Jeff Law , Jakub Jelinek , Michael Meissner , richard.sandiford@arm.com Cc: gcc@gcc.gnu.org, Richard Biener , Segher Boessenkool , Peter Bergner , Jeff Law , Jakub Jelinek , Michael Meissner Subject: Re: RFC: Make builtin types only valid for some target features References: <372da22f-c33a-9484-7f34-24a2a08d90e1@linux.ibm.com> Date: Mon, 05 Dec 2022 07:31:48 +0000 In-Reply-To: <372da22f-c33a-9484-7f34-24a2a08d90e1@linux.ibm.com> (Kewen Lin's message of "Fri, 2 Dec 2022 16:47:02 +0800") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-33.4 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,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: "Kewen.Lin" writes: > Hi, > > I'm working to find one solution for PR106736, which requires us to > make some built-in types only valid for some target features, and > emit error messages for the types when the condition isn't satisfied. > A straightforward idea is to guard the registry of built-in type under > the corresponding target feature. But as Peter pointed out in the > PR, it doesn't work, as these built-in types are used by some built-in > functions which are required to be initialized always regardless of > target features, in order to support target pragma/attribute. For > the validity checking on the built-in functions, it happens during > expanding the built-in functions calls, since till then we already > know the exact information on specific target feature. > > One idea is to support built-in type checking in a similar way, to > check if all used type_decl (built-in type) are valid or not somewhere. > I hacked to simply check currently expanding gimple stmt is gassign > and further check the types of its operands, it did work but checking > gassign isn't enough. Maybe I missed something, there seems not an > efficient way for a full check IMHO. > > So I tried another direction, which was inspired by the existing > attribute altivec, to introduce an artificial type attribute and the > corresponding macro definition, during attribute handling it can check > target option node about target feature for validity. The advantage > is that the checking happens in FE, so it reports error early, and it > doesn't need a later full checking on types. But with some prototyping > work, I found one issue that it doesn't support param decl well, since > the handling on attributes of function decl happens after that on > attributes of param decl, so we aren't able to get exact target feature > information when handling the attributes on param decl. It requires > front-end needs to change the parsing order, I guess it's not acceptable? > So I planed to give up and return to the previous direction. > > Does the former idea sound good? Any comments/suggestions, and other > ideas? > > Thanks a lot in advance! 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" [(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); machine_mode intmode = int_mode_for_size (GET_MODE_BITSIZE (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. Thanks, Richard