[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2505052357091.31828@angie.orcam.me.uk>
Date: Tue, 6 May 2025 00:13:13 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Linus Torvalds <torvalds@...ux-foundation.org>
cc: Nathan Chancellor <nathan@...nel.org>, llvm@...ts.linux.dev,
linux-kernel@...r.kernel.org
Subject: Re: Adding __popcountsi2 and __popcountdi2
On Mon, 5 May 2025, Linus Torvalds wrote:
> > > Once you have the overhead of a function call - and all the register
> > > games etc that involves, you're almost certainly better off with the
> > > simple unconditional bitwise games.
> >
> > Unless optimising for size, which we do support.
>
> I think you missed the part where I said
>
> "But if you want to do this, put the damn thing as an alias on the code
> that actually *does* the SW fallback in lib/hweight.c."
>
> IOW, what I object to is being *stupid* and doing *two* function
> calls. It sure as hell doesn't optimize for size.
Sure, I only commented on whether or not to have entry points defined in
the link for libcalls that GCC emits whenever it produces a `popcount'
operation it cannot find a machine description pattern for (IOW a machine
instruction or a favourable sequence of).
They need to have specific names a per the subject and it's up to us to
implement them one way or another should we choose to; and as I say it
seems not unreasonable to me for GCC to emit these libcalls at least when
optimising for size.
Traditionally we have chosen not to implement double-precision division
libcalls so as to trap expensive usage. For `popcount' I have no opinion
offhand.
Maciej
Powered by blists - more mailing lists