From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by sourceware.org (Postfix) with ESMTPS id D0A5A385842E for ; Wed, 22 Sep 2021 05:17:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D0A5A385842E Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 18M2AAvM032615; Wed, 22 Sep 2021 01:17:30 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3b7tkwbkr3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 01:17:30 -0400 Received: from m0098409.ppops.net (m0098409.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 18M51D1L031167; Wed, 22 Sep 2021 01:17:29 -0400 Received: from ppma06fra.de.ibm.com (48.49.7a9f.ip4.static.sl-reverse.com [159.122.73.72]) by mx0a-001b2d01.pphosted.com with ESMTP id 3b7tkwbkqk-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 01:17:29 -0400 Received: from pps.filterd (ppma06fra.de.ibm.com [127.0.0.1]) by ppma06fra.de.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 18M5E1ub001807; Wed, 22 Sep 2021 05:17:27 GMT Received: from b06avi18626390.portsmouth.uk.ibm.com (b06avi18626390.portsmouth.uk.ibm.com [9.149.26.192]) by ppma06fra.de.ibm.com with ESMTP id 3b7q6pa3rv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 22 Sep 2021 05:17:27 +0000 Received: from d06av25.portsmouth.uk.ibm.com (d06av25.portsmouth.uk.ibm.com [9.149.105.61]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 18M5Ccsg52298026 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Wed, 22 Sep 2021 05:12:38 GMT Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id F065711C05B; Wed, 22 Sep 2021 05:17:24 +0000 (GMT) Received: from d06av25.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ADAC611C050; Wed, 22 Sep 2021 05:17:23 +0000 (GMT) Received: from kewenlins-mbp.cn.ibm.com (unknown [9.200.147.34]) by d06av25.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 22 Sep 2021 05:17:23 +0000 (GMT) Subject: Re: [PATCH] rs6000: Parameterize some const values for density test To: Segher Boessenkool Cc: GCC Patches , Bill Schmidt , David Edelsohn References: <20210917222627.GY1583@gate.crashing.org> <360285e1-bee7-3336-83aa-30de1dd08199@linux.ibm.com> <20210921120332.GB1583@gate.crashing.org> From: "Kewen.Lin" Message-ID: <363e6c6e-6a8c-0cb5-a1ab-699fd482c5f0@linux.ibm.com> Date: Wed, 22 Sep 2021 13:17:22 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.0 MIME-Version: 1.0 In-Reply-To: <20210921120332.GB1583@gate.crashing.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: z6AztqVCNCXNYL4JRJg42hyC82L65exz X-Proofpoint-GUID: LCADj9WZQ5iRcgGLYAVErZ9noOt1mhYg X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.182.1,Aquarius:18.0.790,Hydra:6.0.391,FMLib:17.0.607.475 definitions=2021-09-22_01,2021-09-20_01,2020-04-07_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 priorityscore=1501 mlxlogscore=999 suspectscore=0 mlxscore=0 malwarescore=0 adultscore=0 clxscore=1015 impostorscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2109200000 definitions=main-2109220033 X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Sep 2021 05:17:33 -0000 on 2021/9/21 下午8:03, Segher Boessenkool wrote: > Hi! > > On Tue, Sep 21, 2021 at 01:47:19PM +0800, Kewen.Lin wrote: >> on 2021/9/18 上午6:26, Segher Boessenkool wrote: >>>> + if (data->nloads > (unsigned int) rs6000_density_load_num_threshold >>>> + && load_pct > (unsigned int) rs6000_density_load_pct_threshold) >>> >>> Those variables are unsigned int already. Don't cast please. >> >> Unfortunately this is required by bootstrapping. The UInteger for the >> param definition is really confusing, in the underlying implementation >> it's still "signed". If you grep "(unsigned) param", you can see a few >> examples. I guess the "UInteger" is mainly for the param value range >> checking. > > Huh, I see. Is that a bug? It certainly is surprising! Please open a > PR if you think it could/should be improved, put me on Cc:? > I guessed it's not a bug, "UInteger" is more for the opt/param value range checking, but could be improved. PR102440 filed as you suggested. :) >>>> +-param=rs6000-density-pct-threshold= >>>> +Target Undocumented Joined UInteger Var(rs6000_density_pct_threshold) Init(85) IntegerRange(0, 99) Param >>> >>> So make this and all other percentages (0, 100) please. >> >> I thought 99 is enough for the RHS in ">". just realized it's more clear >> with 100. Will fix! > > 99 will work fine, but it's not the best choice for the user, who will > expect that a percentage can be anything from 0% to 100%. > >>>> +When costing for loop vectorization, we probably need to penalize the loop body cost if the existing cost model may not adequately reflect delays from unavailable vector resources. We collect the cost for vectorized statements and non-vectorized statements separately, check the proportion of vec_cost to total cost of vec_cost and non vec_cost, and penalize only if the proportion exceeds the threshold specified by this parameter. The default value is 85. >>> >>> It would be good if we can use line breaks in the source code for things >>> like this, but I don't think we can. This message is mainly used for >>> "--help=param", and it is good there to have as short messages as you >>> can. But given the nature of params you need quite a few words often, >>> and you do not want to say so little that things are no clear, either. >>> >>> So, dunno :-) >> >> I did some testings, the line breaks writing can still survive in the >> "--help=param" show, the lines are concatenated with " ". Although >> there seems no this kind of writing practices, I am guessing you want >> me to do line breaks for their descriptions? If so, I will make them >> short as the above "Target Undocumented..." line. Or do you want it >> to align source code ColumnLimit 80 (for these cases, it would look >> shorter)? > > It would help if was more readable in the surce code, one line of close > to 500 columns is not very manageable :-) > > But the thing that matters is what it will look like in the --help= > output (and/or the manual). > OK, I've used ColumnLimit 80 for that. The outputs in --help= before/after the line breaks look the same (smoother than what I can expect). :) Committed in r12-3767, thanks! BR, Kewen