From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from vsmx011.vodafonemail.xion.oxcs.net (vsmx011.vodafonemail.xion.oxcs.net [153.92.174.89]) by sourceware.org (Postfix) with ESMTPS id 1DC113857C4F for ; Wed, 25 Nov 2020 23:12:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 1DC113857C4F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=nexgo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=stefan.kanthak@nexgo.de Received: from vsmx003.vodafonemail.xion.oxcs.net (unknown [192.168.75.197]) by mta-5-out.mta.xion.oxcs.net (Postfix) with ESMTP id A740C59DBB9; Wed, 25 Nov 2020 23:12:22 +0000 (UTC) Received: from H270 (unknown [91.56.252.193]) by mta-7-out.mta.xion.oxcs.net (Postfix) with ESMTPA id DC4F95399E0; Wed, 25 Nov 2020 23:12:11 +0000 (UTC) Message-ID: <701788C189064AA0B816C484A95C654B@H270> From: "Stefan Kanthak" To: "Jakub Jelinek" , "Jeff Law" Cc: "Andreas Schwab" , , "Eric Botcazou" References: <116F1589A8244FB494091BCD4E6398AB@H270> <7786108.h9Zq5u0u6d@fomalhaut> <003190C0741B4AF0B73E189026EADC84@H270> <87zh3oiwya.fsf@igel.home> <87o8jmu8m8.fsf@igel.home> <20201125204213.GL3788@tucnak> <1A10C4A4DE43499BB4C6C41765474DA3@H270> In-Reply-To: Subject: Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function Date: Thu, 26 Nov 2020 00:06:05 +0100 Organization: Me, myself & IT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Windows Mail 6.0.6002.18197 X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7601.24158 X-VADE-STATUS: LEGIT X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, 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: Wed, 25 Nov 2020 23:12:26 -0000 Jeff Law wrote: [...] > By understanding how your proposed changes affect other processors, you > can write better changes that are more likely to get included. > Furthermore you can focus efforts on things that matter more in the real > world. DImode shifts in libgcc are _not_ useful to try and optimize on > x86_64 as it has instructions to implement 64 bit shifts. DImode shifts > in libgcc are not useful to try and optimize on i686 as the compiler can > synthesize them on i686. DImode shifts can't be easily synthesized on > other targets and on those targets we call the routines in libgcc2. > Similarly for other routines you find in libgcc2. What makes you think that my patches addressed only i386 and AMD64? Again: from the absence of __addDI3/__subDI3 in libgcc2.[ch] I had reason to assume that GCC synthesizes "double-word" addition/subtraction on all processors, not just on x86. Since "double-word" comparision and shifts are likewise simple operations I further assumed that GCC synthesizes them too on all processors. What's the fundamental difference between subtraction and comparision? Why does GCC generate calls to __[u]cmpDI2 for a simple comparision instead to synthesize it? And: as shown in libgcc2.c, "double-word" shifts can easily be synthesized using "single-word" shifts plus logical OR on any target. I expected GCC to synthesize these operations on non-x86 processors too, just like "double-word" addition and subtraction. A possible/reasonable explanation would be code size, i.e. if the synthesized instructions need significantly more memory than the function call (including the argument setup of course). Stefan