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 34D733858D32 for ; Wed, 19 Oct 2022 02:53:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 34D733858D32 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 (m0127361.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.17.1.5/8.17.1.5) with ESMTP id 29J2hpVo035191; Wed, 19 Oct 2022 02:53:13 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pp1; bh=/vpV62sA+yyyPxAx7jl2QnUhZWUYxYNZTsgr+w4aa0c=; b=hQoZrBMO85rPSozs3cYEtr+urwLWuOktQhEtqvMiFXZaqvX87oZj655oTxB+La1bKUSJ BGqK6su1YD50Njiozt+c5lrBPaTsW5A7mbMuHk/dFcUbAe3i+LJPhLt4O7coHlHC0jp+ kuk1nVYZzWXgSX9iaLu+bAXaBI5V89fz4FHTaemyxIG6AcsXrXcWEYjK1lyx2DYA84Jy Fe5kMBBkf2EmJA7rfQojzRUyTXzOgjleLV7afSL737w/wh9yksXfCdBo4tUa+0CvMHu3 6sSRfugZY5yOAfMprPilaqD+G1WbK7YIRi444xV8MPoUSgbff4fcMDbH3+gT5SJK1qCO /Q== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ka8pyg72t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 02:53:13 +0000 Received: from m0127361.ppops.net (m0127361.ppops.net [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 29J2i5Lt037463; Wed, 19 Oct 2022 02:53:13 GMT Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0a-001b2d01.pphosted.com (PPS) with ESMTPS id 3ka8pyg70t-4 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 02:53:13 +0000 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 29J2ZBaO025990; Wed, 19 Oct 2022 02:37:05 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma03ams.nl.ibm.com with ESMTP id 3k7mg969ef-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 19 Oct 2022 02:37:04 +0000 Received: from b06wcsmtp001.portsmouth.uk.ibm.com (b06wcsmtp001.portsmouth.uk.ibm.com [9.149.105.160]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 29J2W3LL37617962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 19 Oct 2022 02:32:03 GMT Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C1D72A4054; Wed, 19 Oct 2022 02:37:02 +0000 (GMT) Received: from b06wcsmtp001.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DB4DDA405B; Wed, 19 Oct 2022 02:37:00 +0000 (GMT) Received: from [9.197.229.72] (unknown [9.197.229.72]) by b06wcsmtp001.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 19 Oct 2022 02:37:00 +0000 (GMT) Message-ID: Date: Wed, 19 Oct 2022 10:36:59 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Subject: Re: [PATCH, rs6000] Split TARGET_POWER8 from TARGET_DIRECT_MOVE [PR101865] (2/2) Content-Language: en-US To: Segher Boessenkool , will schmidt Cc: GCC patches , David Edelsohn , Michael Meissner References: <2656f0182df289ade33411ac579d2d5a229f5e4c.camel@vnet.ibm.com> <20221017180840.GJ25951@gate.crashing.org> <20221018165229.GK25951@gate.crashing.org> From: "Kewen.Lin" In-Reply-To: <20221018165229.GK25951@gate.crashing.org> Content-Type: text/plain; charset=UTF-8 X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: 3_9BcydyeHPKVoUGns5xdrpWy5-gChXg X-Proofpoint-GUID: 8LseEPU-adN90twr_Y_04xUSg6hNp5Tb 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.895,Hydra:6.0.545,FMLib:17.11.122.1 definitions=2022-10-18_10,2022-10-18_01,2022-06-22_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 lowpriorityscore=0 spamscore=0 mlxscore=0 malwarescore=0 bulkscore=0 mlxlogscore=999 impostorscore=0 phishscore=0 adultscore=0 clxscore=1015 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2209130000 definitions=main-2210190012 X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,GIT_PATCH_0,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! on 2022/10/19 00:52, Segher Boessenkool wrote: > Hi! > > On Tue, Oct 18, 2022 at 10:17:30AM -0500, will schmidt wrote: >> On Mon, 2022-10-17 at 13:08 -0500, Segher Boessenkool wrote: >>> It did not happen in GCC 9 obviously. Do you want to take a >>> shot? It >>> doesn't have to be all at once, it's probably best if not even -- as >>> I >>> wrote in the commit message, the flag always was used to mean >>> different >>> things. >> >> As long as it's OK to be removed, I'll certainly take a shot at it. > > It is. Thanks! > >> With that in mind that may simplify things for me here. >> I expect that >> anything currently guarded by DIRECT_MOVE should instead be guarded by >> POWER8. > > Yes. Which works just as well for the places that actually check > whether the direct move insns can be used, and for everything else that > wants p8 :-) > IIUC, this discussion is saying we want to replace all TARGET_DIRECT_MOVE with TARGET_POWER8? I may miss something but it sounds wrong to me. Currently TARGET_DIRECT_MOVE is used to guard many places which rely on vector (VSR) support. One example is one place quoted from [1]: > diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md > index e226a93bbe55..be4fb902049d 100644 > --- a/gcc/config/rs6000/vsx.md > +++ b/gcc/config/rs6000/vsx.md > @@ -3407,11 +3407,11 @@ (define_insn "vsx_extract_" > if (element == VECTOR_ELEMENT_SCALAR_64BIT) > { > if (op0_regno == op1_regno) > return ASM_COMMENT_START " vec_extract to same register"; > > - else if (INT_REGNO_P (op0_regno) && TARGET_DIRECT_MOVE > + else if (INT_REGNO_P (op0_regno) && TARGET_POWER8 > && TARGET_POWERPC64) > return "mfvsrd %0,%x1"; Now we want TARGET_POWER8 still on if users specify -mcpu=power8 -mno-vsx, if we guard the above with TARGET_POWER8, it would mean we can still have "mfvsrd" but it shouldn't be available as it relies on VSX support which gets disabled explicitly. So for these kinds of uses of TARGET_DIRECT_MOVE which are for actual "direct move" insns, they should be guarded with TARGET_P8_VECTOR instead? [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603724.html BR, Kewen