From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0b-001b2d01.pphosted.com (mx0b-001b2d01.pphosted.com [148.163.158.5]) by sourceware.org (Postfix) with ESMTPS id 434513858D39 for ; Fri, 2 Dec 2022 08:47:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 434513858D39 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 (m0098421.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 2B281g7G024557; Fri, 2 Dec 2022 08:47:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : to : cc : from : subject : content-type : content-transfer-encoding; s=pp1; bh=8DzUGllwb431igSfbiJ2YI4fBiEmn5DGbIhnOwVpb/Q=; b=qBJ7FsJoGBWzh8VLsxfWV4Mk/dHVzmzb+ZbdE5DOIc1W2dvy2Ucz/48DIyBw4MQ1jOjR qf4ZFthe9Wx1bCmO6aoEjeiBADtCrbXcXTugp8/76wr0oH9JkQ5d+5LivelEvpYGwBKZ T+Z9/P/S4bjkthfB8emAMRwoL3GugjOX7pGZLb9+TzmeC2vucEJpJrmTqUtivsZpXcJd 8wHNVT5cOwxTU3ROWrNUPS3kyRW979hHWdm9GZH5Ps7KD2ayS7SXWP+G/G8WhsdRdXck Od3wkAT57cVHwxznPw9CDBfiMAngz1q05rSVt7fbS3a9i6kRllUmpFMu4I/UfMbthvQm sA== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m7dg9137y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Dec 2022 08:47:14 +0000 Received: from m0098421.ppops.net (m0098421.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 2B28YpWb007560; Fri, 2 Dec 2022 08:47:13 GMT Received: from ppma05fra.de.ibm.com (6c.4a.5195.ip4.static.sl-reverse.com [149.81.74.108]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3m7dg91379-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Dec 2022 08:47:13 +0000 Received: from pps.filterd (ppma05fra.de.ibm.com [127.0.0.1]) by ppma05fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 2B28a0c8002217; Fri, 2 Dec 2022 08:47:11 GMT Received: from b06cxnps4075.portsmouth.uk.ibm.com (d06relay12.portsmouth.uk.ibm.com [9.149.109.197]) by ppma05fra.de.ibm.com with ESMTP id 3m3ae9ece7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 02 Dec 2022 08:47:11 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06cxnps4075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 2B28l8Hh39911938 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 2 Dec 2022 08:47:08 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1A65CA405B; Fri, 2 Dec 2022 08:47:08 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 8F38FA4054; Fri, 2 Dec 2022 08:47:04 +0000 (GMT) Received: from [9.197.236.147] (unknown [9.197.236.147]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 2 Dec 2022 08:47:04 +0000 (GMT) Message-ID: <372da22f-c33a-9484-7f34-24a2a08d90e1@linux.ibm.com> Date: Fri, 2 Dec 2022 16:47:02 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: gcc@gcc.gnu.org Cc: Richard Biener , Richard Sandiford , Segher Boessenkool , Peter Bergner , Jeff Law , Jakub Jelinek , Michael Meissner From: "Kewen.Lin" Subject: RFC: Make builtin types only valid for some target features Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: dICogkRBkCwIG9ffy2S6gg8EJN5jYBDH X-Proofpoint-GUID: 9ekc0wIaoUoZCBeUBqWinKZHLxPFA_lw X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.219,Aquarius:18.0.923,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-12-02_04,2022-12-01_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 suspectscore=0 mlxlogscore=645 priorityscore=1501 impostorscore=0 malwarescore=0 lowpriorityscore=0 adultscore=0 bulkscore=0 phishscore=0 clxscore=1011 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000 definitions=main-2212020065 X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,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, 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! BR, Kewen