From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id AE274382E750 for ; Tue, 6 Dec 2022 01:42:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org AE274382E750 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux.ibm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linux.ibm.com Received: from pps.filterd (m0098419.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B5MfIar028205; Tue, 6 Dec 2022 01:42:02 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : references : cc : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=9xr5F3A8WfiN50amR4ws+qCAsobQ4LzdCM86tAxUjbQ=; b=hFn+536HLjGtzpCVEGjPZWq9Caf9rQbP3+unxqlGNQsCHaVYSMt5L5YPsiHStY9BDWz9 AoYK6q9t/1sGjNtxG6eEZuguIPsctMKbIAsnxjMuXhrKN8Zhtwas9+j6CV9f7fyM9yJl iEi5+mbpnQwdh2aUTIbxjMksM9KkdRjvpeqjqzHiaVw3arC++eeXeXbpGdlDnzptDmfH xPOgCfj+DjTJdfRs5jzg6LwassNkVN0NvNgjcRHVfvjG4fAmwnJ5XGQTM9KRKZgwUYJA JVmdLHoPFH6h5Y09/g08d+R5iqyX+2DUG6MDQ95RLVoghCffRVpnRlFys5eUspDcWQV3 FQ== Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3m8g1s515g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Dec 2022 01:42:01 +0000 Received: from m0098419.ppops.net (m0098419.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2B61JYwN015067; Tue, 6 Dec 2022 01:42:01 GMT Received: from ppma01fra.de.ibm.com (46.49.7a9f.ip4.static.sl-reverse.com [159.122.73.70]) by mx0b-001b2d01.pphosted.com (PPS) with ESMTPS id 3m8g1s5152-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Dec 2022 01:42:01 +0000 Received: from pps.filterd (ppma01fra.de.ibm.com [127.0.0.1]) by ppma01fra.de.ibm.com (8.17.1.19/8.16.1.2) with ESMTP id 2B5K5ISN004900; Tue, 6 Dec 2022 01:41:59 GMT Received: from smtprelay01.fra02v.mail.ibm.com ([9.218.2.227]) by ppma01fra.de.ibm.com (PPS) with ESMTPS id 3m9pv9r89t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 06 Dec 2022 01:41:59 +0000 Received: from d06av24.portsmouth.uk.ibm.com ([9.149.105.60]) by smtprelay01.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2B61ftPl42598764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 6 Dec 2022 01:41:55 GMT Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 5173142041; Tue, 6 Dec 2022 01:41:55 +0000 (GMT) Received: from d06av24.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DA9C14203F; Tue, 6 Dec 2022 01:41:51 +0000 (GMT) Received: from [9.197.224.206] (unknown [9.197.224.206]) by d06av24.portsmouth.uk.ibm.com (Postfix) with ESMTP; Tue, 6 Dec 2022 01:41:51 +0000 (GMT) Message-ID: <763a5dba-9451-518c-0fed-0b9b0a41b9b0@linux.ibm.com> Date: Tue, 6 Dec 2022 09:41:50 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: RFC: Make builtin types only valid for some target features Content-Language: en-US To: Andrew Pinski References: <372da22f-c33a-9484-7f34-24a2a08d90e1@linux.ibm.com> Cc: Richard Sandiford , gcc@gcc.gnu.org, Richard Biener , Peter Bergner , Segher Boessenkool , Michael Meissner , Jeff Law , Jakub Jelinek From: "Kewen.Lin" In-Reply-To: Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-GUID: CaTHQgzPSp1-KG4yGramgNEQbJ4v4Ghz X-Proofpoint-ORIG-GUID: _DPfWGPL3KhnlL9xwQ9roFatJJIA7jOU Content-Transfer-Encoding: 7bit X-Proofpoint-UnRewURL: 0 URL was un-rewritten MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-05_01,2022-12-05_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 impostorscore=0 malwarescore=0 bulkscore=0 lowpriorityscore=0 clxscore=1015 phishscore=0 spamscore=0 mlxscore=0 adultscore=0 suspectscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212060007 X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,KAM_SHORT,NICE_REPLY_A,RCVD_IN_MSPIKE_H2,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: Hi Andrew, on 2022/12/5 18:10, Andrew Pinski wrote: > On Sun, Dec 4, 2022 at 11:33 PM Richard Sandiford via Gcc > wrote: >> >> "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. > > I did have a patch which improved the situation for the SVE types to > provide an error message at compile time when SVE is not enabled > but I didn't get any feedback from either the C or C++ front-end folks. > https://gcc.gnu.org/pipermail/gcc-patches/2021-November/583786.html > Nice! Many thanks for providing this new direction. > I suspect if that patch gets reviewed by the front-end folks, Kewen > could use the same infrastructure to error out on the types for rs6000 > backend. Yeah, I just confirmed that on top of your patch introducing function rs6000_verify_type_context to take care of those MMA types can fix the issue in PR106736. TBH, I'm not sure if your patch can cover all possible places where a built-in type can be used, but I guess it can cover the most. BR, Kewen