[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <0963a508-6014-43e4-b64c-89b09538b68e@gaisler.com>
Date: Mon, 18 Nov 2024 09:56:44 +0100
From: Andreas Larsson <andreas@...sler.com>
To: Koakuma <koachan@...tonmail.com>
Cc: "David S. Miller" <davem@...emloft.net>, Andy Lutomirski
<luto@...nel.org>, Thomas Gleixner <tglx@...utronix.de>,
Vincenzo Frascino <vincenzo.frascino@....com>,
Nathan Chancellor <nathan@...nel.org>,
Nick Desaulniers <ndesaulniers@...gle.com>, Bill Wendling
<morbo@...gle.com>, Justin Stitt <justinstitt@...gle.com>,
sparclinux@...r.kernel.org, linux-kernel@...r.kernel.org,
llvm@...ts.linux.dev
Subject: Re: [PATCH v2] sparc/vdso: Add helper function for 64-bit right shift
on 32-bit target
On 2024-11-17 00:44, Koakuma wrote:
> Andreas Larsson <andreas@...sler.com> wrote:
>> Koakuma via B4 Relay wrote:
>>> +notrace static __always_inline u64 __shr64(u64 val, int amt)
>>> +{
>>> + u64 ret;
>>> +
>>> + asm volatile("sllx %H1, 32, %%g1\n\t"
>>> + "srl %L1, 0, %L1\n\t"
>>> + "or %%g1, %L1, %%g1\n\t"
>>> + "srlx %%g1, %2, %L0\n\t"
>>> + "srlx %L0, 32, %H0"
>>> + : "=r" (ret)
>>> + : "r" (val), "r" (amt)
>>> + : "g1");
>>> + return ret;
>>> +}
>>
>> Can not residual in bits 63:32 of %L0 potentially pose a problem?
>
> It shouldn't be a problem, upon returning the caller should treat
> the upper bits of %L0 as an unspecified value and not depend on/use
> its contents.
Yes, of course. Lapse of logic on my part.
Reviewed-by: Andreas Larsson <andreas@...sler.com>
Picking this up to my for-next.
Thanks,
Andreas
Powered by blists - more mailing lists