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 5FA913858C53 for ; Wed, 7 Feb 2024 09:21:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5FA913858C53 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 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5FA913858C53 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=148.163.158.5 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707297684; cv=none; b=fLQB7bRnopj02ZI1zx/XOngaVAFw5Ed5HGqMpWga+//YJ4unhV3qIeN4uaXplr6chLiUr9xJ1yss/iMbAqXdeQm9yvSFs3IN11eu/bDH8AxgliTKysmao068ZISBowYH0yetLkizSWgcKYZyj7LzePDq05H5rdM3wlBATjrbbSM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1707297684; c=relaxed/simple; bh=+TDMtS/gRHPjhXD0aY5wGtLOEFS57cyeg1Wza7xPvRM=; h=DKIM-Signature:Message-ID:Date:MIME-Version:From:Subject:To; b=dm328TlDZXSVmKOc80/42dd5L0QOwVSZ+BR0lNUkqr0n1LYzCuy5L1HeU0ADdysUP2MpUF+3jWlqbUBYGiH3ciSqcXB0dfPtlXm3oOxmEwXoe6rTq/W2++5qWiPqRoZCY/wUqEAkG4oGZ4Xjg06vOoIwM/lDKyRdt8JjW8+OxYg= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from pps.filterd (m0353723.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 4177sxdL015397; Wed, 7 Feb 2024 09:21:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : from : subject : to : cc : references : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=amXi3CBKB/ZOw0iK1fsIUeX8l28OUr5QV8KBui6AjJY=; b=Ji4/lrUoGv5RTWTsHIUsBpiWluIQ1/Y2JMqZqEPMxcTZiPJvUE4wCSdIgpsosDYwW7di GJNO2Etx7pPNVbSFc/TViJbPlIgBY6d8+n5pABDyWPvsg1wB26A40hLMkou0bczKE03X YZWKZxpV2/hjC8UaaiBLA2M7uHYMaPBnS620asop7XL+2DGUpxMuaTnToEd7D7HQ8rsh VdgbzUasbT4SpwgbB8mhhds5Lp+VDpYI1RfA2+Ts/0Lc1EcYuCh52w7O6uOac0ncWotX xd4dWnsGyRGPfKKRPfPoTL+t4b0+Bs/0li7HAAyx8hqumYKUfmpBPPiw01iPtisoWoBq yg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3w45vwt3hf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2024 09:21:19 +0000 Received: from m0353723.ppops.net (m0353723.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4177t1bY015527; Wed, 7 Feb 2024 09:21:19 GMT Received: from ppma12.dal12v.mail.ibm.com (dc.9e.1632.ip4.static.sl-reverse.com [50.22.158.220]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3w45vwt3h6-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2024 09:21:18 +0000 Received: from pps.filterd (ppma12.dal12v.mail.ibm.com [127.0.0.1]) by ppma12.dal12v.mail.ibm.com (8.17.1.19/8.17.1.19) with ESMTP id 4176Mohw020371; Wed, 7 Feb 2024 09:21:18 GMT Received: from smtprelay02.fra02v.mail.ibm.com ([9.218.2.226]) by ppma12.dal12v.mail.ibm.com (PPS) with ESMTPS id 3w1ytt52p8-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2024 09:21:18 +0000 Received: from smtpav01.fra02v.mail.ibm.com (smtpav01.fra02v.mail.ibm.com [10.20.54.100]) by smtprelay02.fra02v.mail.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 4179LF7G52691382 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 7 Feb 2024 09:21:15 GMT Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 499F920040; Wed, 7 Feb 2024 09:21:15 +0000 (GMT) Received: from smtpav01.fra02v.mail.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id D961E20043; Wed, 7 Feb 2024 09:21:12 +0000 (GMT) Received: from [9.197.253.35] (unknown [9.197.253.35]) by smtpav01.fra02v.mail.ibm.com (Postfix) with ESMTP; Wed, 7 Feb 2024 09:21:12 +0000 (GMT) Message-ID: <4a7b481d-8967-7f90-ad30-7df955552db8@linux.ibm.com> Date: Wed, 7 Feb 2024 17:21:10 +0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.15.1 From: "Kewen.Lin" Subject: Re: Repost [PATCH 1/6] Add -mcpu=future To: Michael Meissner Cc: gcc-patches@gcc.gnu.org, Segher Boessenkool , David Edelsohn , Peter Bergner References: Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 9-MZk5ofadJF5-TpG82e-M64IFV3ab2v X-Proofpoint-GUID: qeQ2w1bX7SGV2UzwZg0YaG6ot4MGiMdt X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.1011,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-02-07_03,2024-01-31_01,2023-05-22_02 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 clxscore=1015 malwarescore=0 adultscore=0 lowpriorityscore=0 impostorscore=0 spamscore=0 suspectscore=0 mlxscore=0 priorityscore=1501 phishscore=0 mlxlogscore=864 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2311290000 definitions=main-2402070068 X-Spam-Status: No, score=-12.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: on 2024/2/6 14:01, Michael Meissner wrote: > On Tue, Jan 23, 2024 at 04:44:32PM +0800, Kewen.Lin wrote: ... >>> diff --git a/gcc/config/rs6000/rs6000-opts.h b/gcc/config/rs6000/rs6000-opts.h >>> index 33fd0efc936..25890ae3034 100644 >>> --- a/gcc/config/rs6000/rs6000-opts.h >>> +++ b/gcc/config/rs6000/rs6000-opts.h >>> @@ -67,7 +67,9 @@ enum processor_type >>> PROCESSOR_MPCCORE, >>> PROCESSOR_CELL, >>> PROCESSOR_PPCA2, >>> - PROCESSOR_TITAN >>> + PROCESSOR_TITAN, >>> + >> >> Nit: unintentional empty line? >> >>> + PROCESSOR_FUTURE >>> }; > > It was more as a separation. The MPCCORE, CELL, PPCA2, and TITAN are rather > old processors. I don't recall why we kept them after the POWER. > > Logically we should re-order the list and move MPCCORE, etc. earlier, but I > will delete the blank line in future patches. Thanks for clarifying, the re-order thing can be done in a separate patch and in this context one comment line would be better than a blank line. :) ... >>> + power10 tuning until future tuning is added. */ >>> if (rs6000_tune_index >= 0) >>> - tune_index = rs6000_tune_index; >>> + { >>> + enum processor_type cur_proc >>> + = processor_target_table[rs6000_tune_index].processor; >>> + >>> + if (cur_proc == PROCESSOR_FUTURE) >>> + { >>> + static bool issued_future_tune_warning = false; >>> + if (!issued_future_tune_warning) >>> + { >>> + issued_future_tune_warning = true; >> >> This seems to ensure we only warn this once, but I noticed that in rs6000/ >> only some OPT_Wpsabi related warnings adopt this way, I wonder if we don't >> restrict it like this, for a tiny simple case, how many times it would warn? > > In a simple case, you would only get the warning once. But if you use > __attribute__((__target__(...))) or #pragma target ... you might see it more > than once. OK, considering we only get this warning once for a simple case, I'm inclined not to keep a static variable for it, it's the same as what we do currently for option conflict errors emission. But I'm fine for either. >>> else >>> { >>> - size_t i; >>> enum processor_type tune_proc >>> = (TARGET_POWERPC64 ? PROCESSOR_DEFAULT64 : PROCESSOR_DEFAULT); >>> >>> - tune_index = -1; >>> - for (i = 0; i < ARRAY_SIZE (processor_target_table); i++) >>> - if (processor_target_table[i].processor == tune_proc) >>> - { >>> - tune_index = i; >>> - break; >>> - } >>> + tune_index = rs600_cpu_index_lookup (tune_proc == PROCESSOR_FUTURE >>> + ? PROCESSOR_POWER10 >>> + : tune_proc); >> >> This part looks useless, as tune_proc is impossible to be PROCESSOR_FUTURE. > > Well in theory, you could configure the compiler with --with-cpu=future or > --with-tune=future. Sorry for the possible confusion here, the "tune_proc" that I referred to is the variable in the above else branch: enum processor_type tune_proc = (TARGET_POWERPC64 ? PROCESSOR_DEFAULT64 : PROCESSOR_DEFAULT); It's either PROCESSOR_DEFAULT64 or PROCESSOR_DEFAULT, so it doesn't have a chance to be PROCESSOR_FUTURE, so the checking "tune_proc == PROCESSOR_FUTURE" is useless. That's why I suggested the below flow, it does a final check out of those checks, it looks a bit more clear IMHO. > >>> } >> >> Maybe re-structure the above into: >> >> bool explicit_tune = false; >> if (rs6000_tune_index >= 0) >> { >> tune_index = rs6000_tune_index; >> explicit_tune = true; >> } >> else if (cpu_index >= 0) >> // as before >> rs6000_tune_index = tune_index = cpu_index; >> else >> { >> //as before >> ... >> } >> >> // Check tune_index here instead. >> >> if (processor_target_table[tune_index].processor == PROCESSOR_FUTURE) >> { >> tune_index = rs6000_cpu_index_lookup (PROCESSOR_POWER10); >> if (explicit_tune) >> warn ... >> } >> >> // as before >> rs6000_tune = processor_target_table[tune_index].processor; >> >>> BR, Kewen