From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id 57837385780E for ; Tue, 10 Nov 2020 18:32:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 57837385780E Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-454-tZ5gm_lGPvmtYj4Hd0MVpw-1; Tue, 10 Nov 2020 13:32:54 -0500 X-MC-Unique: tZ5gm_lGPvmtYj4Hd0MVpw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 37B0C5F9DB; Tue, 10 Nov 2020 18:32:53 +0000 (UTC) Received: from localhost.localdomain (ovpn-114-181.phx2.redhat.com [10.3.114.181]) by smtp.corp.redhat.com (Postfix) with ESMTP id F29CE610F3; Tue, 10 Nov 2020 18:32:52 +0000 (UTC) Subject: Re: [PATCH] Better __ashlDI3, __ashrDI3 and __lshrDI3 functions, plus fixed __bswapsi2 function To: Jakub Jelinek , Stefan Kanthak Cc: gcc-patches@gcc.gnu.org References: <116F1589A8244FB494091BCD4E6398AB@H270> <20201110180915.GV3788@tucnak> From: Jeff Law Message-ID: Date: Tue, 10 Nov 2020 11:32:52 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201110180915.GV3788@tucnak> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, 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: Tue, 10 Nov 2020 18:32:59 -0000 On 11/10/20 11:09 AM, Jakub Jelinek via Gcc-patches wrote: > On Tue, Nov 10, 2020 at 06:59:30PM +0100, Stefan Kanthak via Gcc-patches wrote: >> The implementation of the __ashlDI3(), __ashrDI3() and __lshrDI3() functions >> is rather bad, it yields bad machine code at least on i386 and AMD64. >> Since GCC knows how to shift integers twice the register size these functions >> can be written as one-liners. > This looks wrong. If gcc knows how to do that inline, it will not call the > out of line function at all. The functions are there for the cases where > gcc can't do that. > So, your patch will shorten the routines on targets where those are never > called, and completely break them on any other (resulting in infinite > recursion there). There's a way to test that.  It's possible the expanders know how to handle these cases now.  I'd be surprised (as I was with the [u]cmpdi2), but it's possible.  I can throw it into the tester which will spin all those pesky embedded targets.  If we get infinite recursion it should show up quite clearly. Of course, if the expanders now handle all the cases, then these routines in libgcc2 are dead code and this is a fairly pointless exercise. jeff