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 D50A53858D35 for ; Fri, 31 Jul 2020 13:22:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D50A53858D35 Received: from pps.filterd (m0098420.ppops.net [127.0.0.1]) by mx0b-001b2d01.pphosted.com (8.16.0.42/8.16.0.42) with SMTP id 06VD5S9K185075; Fri, 31 Jul 2020 09:22:01 -0400 Received: from pps.reinject (localhost [127.0.0.1]) by mx0b-001b2d01.pphosted.com with ESMTP id 32mg4neqhh-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 09:22:00 -0400 Received: from m0098420.ppops.net (m0098420.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.36/8.16.0.36) with SMTP id 06VD6axq188680; Fri, 31 Jul 2020 09:22:00 -0400 Received: from ppma03ams.nl.ibm.com (62.31.33a9.ip4.static.sl-reverse.com [169.51.49.98]) by mx0b-001b2d01.pphosted.com with ESMTP id 32mg4neqh1-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 09:22:00 -0400 Received: from pps.filterd (ppma03ams.nl.ibm.com [127.0.0.1]) by ppma03ams.nl.ibm.com (8.16.0.42/8.16.0.42) with SMTP id 06VDG6Co028646; Fri, 31 Jul 2020 13:21:58 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 32gcpx7a16-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 31 Jul 2020 13:21:58 +0000 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06avi18626390.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 06VDKUHl60948800 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 31 Jul 2020 13:20:30 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 32BC2AE053; Fri, 31 Jul 2020 13:21:56 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 17876AE051; Fri, 31 Jul 2020 13:21:54 +0000 (GMT) Received: from KewenLins-MacBook-Pro.local (unknown [9.197.236.127]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Fri, 31 Jul 2020 13:21:53 +0000 (GMT) Subject: Re: [PATCH v4] vect/rs6000: Support vector with length cost modeling To: Richard Biener Cc: Richard Sandiford , GCC Patches , Bill Schmidt , Segher Boessenkool References: <419f1fad-05be-115c-1a53-cb710ae7b2dc@linux.ibm.com> <1aeabdc7-0cf4-055b-a3ec-74c283053cf5@linux.ibm.com> <7d90d154-6a76-c8f5-75f6-1e1057dfcc0f@linux.ibm.com> <4c7c935b-8eaa-1fd7-4357-72fd3239e710@linux.ibm.com> From: "Kewen.Lin" Message-ID: <56089972-e5db-3c02-f04a-69dfa4063c52@linux.ibm.com> Date: Fri, 31 Jul 2020 21:21:52 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-07-31_04:2020-07-31, 2020-07-31 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 lowpriorityscore=0 bulkscore=0 phishscore=0 adultscore=0 clxscore=1015 impostorscore=0 suspectscore=0 malwarescore=0 mlxlogscore=999 priorityscore=1501 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2007310093 X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Fri, 31 Jul 2020 13:22:05 -0000 on 2020/7/31 下午9:01, Richard Biener wrote: > On Fri, Jul 31, 2020 at 2:37 PM Kewen.Lin wrote: >> >> Hi Richards, >> >> on 2020/7/31 下午7:20, Richard Biener wrote: >>> On Fri, Jul 31, 2020 at 1:03 PM Richard Sandiford >>> wrote: >>>> >>>> "Kewen.Lin" writes: >>>>>>> + bool niters_known_p = LOOP_VINFO_NITERS_KNOWN_P (loop_vinfo); >>>>>>> + bool need_iterate_p >>>>>>> + = (!LOOP_VINFO_EPILOGUE_P (loop_vinfo) >>>>>>> + && !vect_known_niters_smaller_than_vf (loop_vinfo)); >>>>>>> + >>>>>>> + /* Init min/max, shift and minus cost relative to single >>>>>>> + scalar_stmt. For now we only use length-based partial vectors on >>>>>>> + Power, target specific cost tweaking may be needed for other >>>>>>> + ports in future. */ >>>>>>> + unsigned int min_max_cost = 2; >>>>>>> + unsigned int shift_cost = 1, minus_cost = 1; >>>>>> >>>>>> Please instead add a scalar_min_max to vect_cost_for_stmt, and use >>>>>> scalar_stmt for shift and minus. There shouldn't be any Power things >>>>>> hard-coded into target-independent code. >>>>>> >>>>> >>>>> Agree! It's not good to leave them there. I thought to wait and see >>>>> if other targets which support vector with length can reuse this, or >>>>> move it to target specific codes then if not sharable. But anyway >>>>> it looks not good, let's fix it. >>> >>> In other generic places like this we simply use three generic scalar_stmt >>> costs. At least I don't see how min_max should be different from it >>> when shift can be the same as minus. Note this is also how we treat >> >> Yeah, normally they (min/max/minus/shift) are taken as scalar_stmt, excepting >> for fine-grain tuning like i386 port, they will use the same cost. On Power9, >> to implement min/max it takes double cycles of the normal scalar operations >> like add/shift, I was trying to model it more fine-grained since we probably >> generate a few min/max here, if the loop body cost is small, I was worried >> the decision isn't good enough. But yeah, in other generic places, the small >> loop could also suffer this similar off, they are the same essentially. >> >>> vectorization of MAX_EXPR - scalar cost is one scalar_stmt and >>> vector cost is one vector_stmt. As you say below the add_stmt_cost >>> hook can adjust based on the actual GIMPLE stmt -- if one is >>> available (which indeed it isn't here). >>> >>> I'm somewhat lacking context here as well - we actually GIMPLE >>> code-generate the min/max/shift/minus and only the eventual >>> AND is defered to the target, right? >>> >> >> Yes, min/max/shift/minus are all GIMPLE code, targets like Power >> will have its target specific cost for shift which moves length >> to high bits 0:7. >> >> One typical case is as below: >> >> [local count: 105119324]: >> _26 = n_11(D) * 4; >> _37 = MAX_EXPR <_26, 16>; >> _38 = _37 + 18446744073709551600; >> _40 = MIN_EXPR <_26, 16>; >> >> [local count: 630715945]: >> # ivtmp_35 = PHI <0(3), ivtmp_36(4)> >> # loop_len_30 = PHI <_40(3), _44(4)> >> _19 = &MEM[base: a_12(D), index: ivtmp_35, offset: 0B]; >> vect_24 = .LEN_LOAD (_19, 4B, loop_len_30); >> vect__3.7_23 = VIEW_CONVERT_EXPR(vect_24); >> _1 = &MEM[base: b_13(D), index: ivtmp_35, offset: 0B]; >> vect_17 = .LEN_LOAD (_1, 4B, loop_len_30); >> vect__5.10_9 = VIEW_CONVERT_EXPR(vect_17); >> vect__7.11_8 = vect__5.10_9 + vect__3.7_23; >> vect_28 = VIEW_CONVERT_EXPR(vect__7.11_8); >> _2 = &MEM[base: c_14(D), index: ivtmp_35, offset: 0B]; >> .LEN_STORE (_2, 4B, loop_len_30, vect_28); >> _42 = MIN_EXPR ; >> _43 = _38 - _42; >> _44 = MIN_EXPR <_43, 16>; >> ivtmp_36 = ivtmp_35 + 16; >> if (ivtmp_35 < _38) >> goto ; [83.33%] >> else >> goto ; [16.67%] >> >> >>>>> I had some concerns on vect_cost_for_stmt way, since it seems to allow >>>>> more computations similar to min/max to be added like this, in long >>>>> term it probably leads to the situtation like: scalar_min_max, >>>>> scalar_div_expr, scalar_mul_expr ... an enum (cost types) bloat, it >>>>> seems not good to maintain. >>>> >>>> I guess doing that doesn't seem so bad to me :-) I think it's been >>>> a recurring problem that the current classification isn't fine-grained >>>> enough for some cases. >>> >>> But we eventually want to get rid of this classification enum in favor >>> of the add_stmt_cost hook ... >>> >> >> Nice, sounds like each target has to handle it fine-grain. :) >> IIUC, the current modeling doesn't consider the instruction dependency and >> execution resource etc. like scheduling, even if all costs are fine-grained >> enough, the decision could be sub-optimal. > > That's what the finish_cost hook is for - the target can collect > all stmts during add_stmt and then apply adjustments at the end > (IIRC power does already for shift operation resource constraints). > oh, forgot that we have that hook, though I just imagined some generic codes would do this. Good to know we have a way to make it. Nice! BR, Kewen