From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20060 invoked by alias); 31 May 2017 08:48:38 -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 19826 invoked by uid 89); 31 May 2017 08:48:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy=31052017, 31.05.2017 X-HELO: mo4-p00-ob.smtp.rzone.de Received: from mo4-p00-ob.smtp.rzone.de (HELO mo4-p00-ob.smtp.rzone.de) (81.169.146.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 31 May 2017 08:48:10 +0000 X-RZG-AUTH: :LXoWVUeid/7A29J/hMvvT3ol15ykJcYwR/bcHRirORRW3yMcVao= X-RZG-CLASS-ID: mo00 Received: from [192.168.0.123] (mail.hightec-rt.com [213.135.1.215]) by smtp.strato.de (RZmta 40.7 DYNA|AUTH) with ESMTPSA id C08cc4t4V8m80tE (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Wed, 31 May 2017 10:48:08 +0200 (CEST) Subject: Re: [PATCH] Optimize divmod expansion (PR middle-end/79665) To: Jakub Jelinek References: <20170222214046.GA1849@tucnak> <99048e22-aedc-df95-f1fe-dc1eaffd58b1@gjlay.de> <20170531081554.GP24023@tucnak> Cc: Jeff Law , gcc-patches@gcc.gnu.org From: Georg-Johann Lay Message-ID: Date: Wed, 31 May 2017 09:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1 MIME-Version: 1.0 In-Reply-To: <20170531081554.GP24023@tucnak> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg02324.txt.bz2 On 31.05.2017 10:15, Jakub Jelinek wrote: > On Wed, May 31, 2017 at 10:06:34AM +0200, Georg-Johann Lay wrote: >> Hi, this causes a performance degradation for avr. >> >> When optimizing for speed, and with a known denominatior, then v6 uses >> s/umulMM3_highpart insn to avoid division because no div instruction is >> available. >> >> unsigned scale256 (unsigned val) >> { >> return value / 255; >> } >> >> With this patch, v7 now uses __divmodhi4 which is very expensive but >> the costs are not computed because rtlanal.c:seq_cost assumes a cost of >> ONE: >> >> for (; seq; seq = NEXT_INSN (seq)) >> { >> set = single_set (seq); >> if (set) >> cost += set_rtx_cost (set, speed); >> else >> cost++; >> } >> >> because divmod in not a single_set: >> (gdb) p seq >> $10 = (const rtx_insn *) 0x7ffff730d500 >> (gdb) pr >> warning: Expression is not an assignment (and might have no effect) >> (insn 14 13 0 (parallel [ >> (set (reg:HI 52) >> (div:HI (reg:HI 47) >> (reg:HI 54))) >> (set (reg:HI 53) >> (mod:HI (reg:HI 47) >> (reg:HI 54))) >> (clobber (reg:QI 21 r21)) >> (clobber (reg:HI 22 r22)) >> (clobber (reg:HI 24 r24)) >> (clobber (reg:HI 26 r26)) >> ]) "scale.c":7 -1 >> (nil)) >> (gdb) >> >> Hence the divmod appears to be much less expensive than the unsigned >> variant that computed the costs for mult_highpart. > > Then you should fix the cost computation - be able to use a target hook > on insns that are not a single set or something similar. > > Jakub > Are you saying that cost computation in GCC is fundamentally flawed for anything that it not a single_set? Johann