From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 85411 invoked by alias); 24 May 2017 07:23:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 78445 invoked by uid 89); 24 May 2017 07:21:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=waterproof, Room X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 07:21:49 +0000 Received: from pps.filterd (m0098409.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v4O7DYu1009070 for ; Wed, 24 May 2017 03:21:51 -0400 Received: from e06smtp15.uk.ibm.com (e06smtp15.uk.ibm.com [195.75.94.111]) by mx0a-001b2d01.pphosted.com with ESMTP id 2an2gey3bf-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for ; Wed, 24 May 2017 03:21:51 -0400 Received: from localhost by e06smtp15.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 24 May 2017 08:21:49 +0100 Received: from b06cxnps3075.portsmouth.uk.ibm.com (9.149.109.195) by e06smtp15.uk.ibm.com (192.168.101.145) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 24 May 2017 08:21:48 +0100 Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps3075.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v4O7LlP214483930; Wed, 24 May 2017 07:21:47 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 41ED1AE053; Wed, 24 May 2017 08:19:45 +0100 (BST) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 1FBE6AE051; Wed, 24 May 2017 08:19:45 +0100 (BST) Received: from oc6142347168.ibm.com (unknown [9.152.212.45]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTP; Wed, 24 May 2017 08:19:45 +0100 (BST) Subject: Re: [PATCH 2/5 v3] Vect peeling cost model To: Richard Biener , GCC Patches , "Bin.Cheng" , Andreas Krebbel , richard.sandiford@linaro.org References: <0296a54f-cb8d-d9b8-380a-9cc553dbb6da@linux.vnet.ibm.com> <2804E9EF-67D1-4EFD-AF29-65C634EBE24F@gmail.com> <6f1194a0-9e57-0028-faf4-6190beec2009@linux.vnet.ibm.com> <3e575f6d-874a-b260-1fc2-f4db1250c32b@linux.vnet.ibm.com> <15b3df5a-f6a1-23f0-57ff-1f065420df19@linux.vnet.ibm.com> <765ae66b-6294-6c39-a101-8c54a6be42ae@linux.vnet.ibm.com> <1c1dfe6c-9e0f-2243-bf79-ff1a8bb0bb02@linux.vnet.ibm.com> <87mva3zaml.fsf@linaro.org> From: Robin Dapp Date: Wed, 24 May 2017 07:37:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <87mva3zaml.fsf@linaro.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 x-cbid: 17052407-0020-0000-0000-00000372B716 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17052407-0021-0000-0000-000041DD5EA4 Message-Id: <5fe88af1-b9dc-ad8d-95e3-9843872f2e58@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2017-05-24_05:,, signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1703280000 definitions=main-1705240034 X-SW-Source: 2017-05/txt/msg01825.txt.bz2 > Not sure I've understood the series TBH, but is the npeel == vf / 2 > there specifically for the "unknown number of peels" case? How do > we distinguish that from the case in which the number of peels is > known to be vf / 2 at compile time? Or have I missed the point > completely? (probably yes, sorry!) Good point, that's not totally waterproof for future uses of vect_get_peeling_costs_all_drs (). Currently, however, only when peeling for unknown alignment vf != 0 will be passed to it (and vf == 0 for the known alignment case), so we can distinguish the cases. In future, the whole vf/2 handling should be improved anyway since e.g. it is hardcoded here as well as in tree-vect-loop.c. npeel = 0 also has a double meaning, namely not peeling when peeling for known alignment and peeling vf/2 iters when peeling for unknown alignment. Room for improvement I guess :) Regards Robin