From patchwork Mon Nov 30 19:05:27 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Pitre X-Patchwork-Id: 11941183 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-15.2 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_CR_TRAILER, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D4475C63777 for ; Mon, 30 Nov 2020 19:06:53 +0000 (UTC) Received: from merlin.infradead.org (merlin.infradead.org [205.233.59.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 3785C20691 for ; Mon, 30 Nov 2020 19:06:53 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="AoBiQCfL"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=pobox.com header.i=@pobox.com header.b="PcKSpcZ9"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=fluxnic.net header.i=@fluxnic.net header.b="Bw0KrWMD" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3785C20691 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=fluxnic.net Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=merlin.20170209; h=Sender:Content-Transfer-Encoding: Content-Type:Cc:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:MIME-Version:Message-ID:Subject:To:From:Date: Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender :Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Owner; bh=502fidMWF6Yms+wHE3mhBS3dKCpyepaKVoCGOC4xKF8=; b=AoBiQCfLS6cDM6jRmiGaTh7kZu bfwJqIRQNeH8Zfh/A+ny9krd+qcXT9JoaRxCi1GdreKD+S4iKOsnk7xRG+Fquyvn7M8PCkvQzcBzy HDim4h5mANZbY9IfS21CuqA3OAw/An5EG8vbjlqw76QK5i1A4zQIF6vz14I+YHFr4EFVrk/Y/SKXo A/0MrQqI9TRsZPV8WLHM0vn7D1Opo8EqYtZgN4akUCITGTaBXHgm/1oVNjF1yWOQ1u9FZWGzK4fSL R/zljisb3i7TNYO2Xc58UMtzKKa9MdeBQoyCj8BbCvtmqPsNVU1YOFhl3dj0qmADv99bF2sdOlyIw Ivi9ALTw==; Received: from localhost ([::1] helo=merlin.infradead.org) by merlin.infradead.org with esmtp (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjoUQ-0000Rp-U5; Mon, 30 Nov 2020 19:05:34 +0000 Received: from pb-smtp1.pobox.com ([64.147.108.70]) by merlin.infradead.org with esmtps (Exim 4.92.3 #3 (Red Hat Linux)) id 1kjoUN-0000Ql-Pj for linux-arm-kernel@lists.infradead.org; Mon, 30 Nov 2020 19:05:32 +0000 Received: from pb-smtp1.pobox.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id A13D996B0F; Mon, 30 Nov 2020 14:05:29 -0500 (EST) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=date:from:to :cc:subject:message-id:mime-version:content-type; s=sasl; bh=o66 fWbDxu+vGpURX5At9CAiXLE4=; b=PcKSpcZ9oM7uDPT45ErjBTVolofrnX5gOWt 5OzWmzw6OvlgeCfThWvwXIplQ4mympN21xsOpMnxDezCjECOoJv1JCreZtXnv10T qrD4+9TpObGzh2WgBYq4+efEAAiMT8hUIr5/0w/AHO0JZvXaR6+WDh2vIvY6ucAU N0z09+3E= Received: from pb-smtp1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-smtp1.pobox.com (Postfix) with ESMTP id 9786996B0E; Mon, 30 Nov 2020 14:05:29 -0500 (EST) (envelope-from nico@fluxnic.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fluxnic.net; h=date:from:to:cc:subject:message-id:mime-version:content-type; s=2016-12.pbsmtp; bh=ErmNPUoVS3ShlHVWHlrVlkcjC8rXScMfTvlvNDZ16wk=; b=Bw0KrWMDblg/4kRnvcZDyUnFY1r9HO+JDXw/iRd6daZX47gC+yXpnbXuEC6Cep2nw7oOjGT7rmmI4CkLbtRsDe8/kwpXfrvMBV96QuGZ5uv30akPbZemVGJJoXehSgzeq/3Bse/u+78jzZw8b+6ufXfqh+nQw9WyMkyeTJ+/yZs= Received: from yoda.home (unknown [24.203.50.76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pb-smtp1.pobox.com (Postfix) with ESMTPSA id 1249A96B0D; Mon, 30 Nov 2020 14:05:29 -0500 (EST) (envelope-from nico@fluxnic.net) Received: from xanadu.home (xanadu.home [192.168.2.2]) by yoda.home (Postfix) with ESMTPSA id E65612DA09EC; Mon, 30 Nov 2020 14:05:27 -0500 (EST) Date: Mon, 30 Nov 2020 14:05:27 -0500 (EST) From: Nicolas Pitre To: Ard Biesheuvel , Antony Yu , Nick Desaulniers , Russell King Subject: [PATCH] __div64_32(): straighten up inline asm constraints Message-ID: MIME-Version: 1.0 X-Pobox-Relay-ID: 02FBCF5A-333F-11EB-B898-D152C8D8090B-78420484!pb-smtp1.pobox.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20201130_140532_001556_1D19BA04 X-CRM114-Status: GOOD ( 16.22 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: clang-built-linux , Nathan Chancellor , Linux Kernel Mailing List , Linux ARM Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org The ARM version of __div64_32() encapsulates a call to __do_div64 with non-standard argument passing. In particular, __n is a 64-bit input argument assigned to r0-r1 and __rem is an output argument sharing half of that 40-r1 register pair. With __n being an input argument, the compiler is in its right to presume that r0-r1 would still hold the value of __n past the inline assembly statement. Normally, the compiler would have assigned non overlapping registers to __n and __rem if the value for __n is needed again. However, here we enforce our own register assignment and gcc fails to notice the conflict. In practice this doesn't cause any problem as __n is considered dead after the asm statement and *n is overwritten. However this is not always guaranteed and clang rightfully complains. Let's fix it properly by making __n into an input-output variable. This makes it clear that those registers representing __n have been modified. Then we can extract __rem as the high part of __n with plain C code. This asm constraint "abuse" was likely relied upon back when gcc didn't handle 64-bit values optimally Turns out that gcc is now able to optimize things and produces the same code with this patch applied. Signed-off-by: Nicolas Pitre Reviewed-by: Ard Biesheuvel Tested-by: Ard Biesheuvel Reported-by: Antony Yu --- This is related to the thread titled "[RESEND,PATCH] ARM: fix __div64_32() error when compiling with clang". My limited compile test with clang appears to make it happy. If no more comments I'll push this to RMK's patch system. diff --git a/arch/arm/include/asm/div64.h b/arch/arm/include/asm/div64.h index 898e9c78a7..595e538f5b 100644 --- a/arch/arm/include/asm/div64.h +++ b/arch/arm/include/asm/div64.h @@ -21,29 +21,20 @@ * assembly implementation with completely non standard calling convention * for arguments and results (beware). */ - -#ifdef __ARMEB__ -#define __xh "r0" -#define __xl "r1" -#else -#define __xl "r0" -#define __xh "r1" -#endif - static inline uint32_t __div64_32(uint64_t *n, uint32_t base) { register unsigned int __base asm("r4") = base; register unsigned long long __n asm("r0") = *n; register unsigned long long __res asm("r2"); - register unsigned int __rem asm(__xh); - asm( __asmeq("%0", __xh) + unsigned int __rem; + asm( __asmeq("%0", "r0") __asmeq("%1", "r2") - __asmeq("%2", "r0") - __asmeq("%3", "r4") + __asmeq("%2", "r4") "bl __do_div64" - : "=r" (__rem), "=r" (__res) - : "r" (__n), "r" (__base) + : "+r" (__n), "=r" (__res) + : "r" (__base) : "ip", "lr", "cc"); + __rem = __n >> 32; *n = __res; return __rem; }