On Thu, Feb 27, 2025 at 09:57:41PM +, David Laight wrote:
> > It's still unclear to me that this parity thing is used in hot paths.
> > If that holds, it's unclear that your hand-made version is better than
> > what's generated by GCC.
>
> I wasn't seriously considering doing that optimisation
On February 27, 2025 1:57:41 PM PST, David Laight
wrote:
>On Thu, 27 Feb 2025 13:05:29 -0500
>Yury Norov wrote:
>
>> On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
>> > On Mon, 24 Feb 2025 14:27:03 -0500
>> > Yury Norov wrote:
>> >
>> > > +#define parity(val)
On Thu, 27 Feb 2025 13:05:29 -0500
Yury Norov wrote:
> On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
> > On Mon, 24 Feb 2025 14:27:03 -0500
> > Yury Norov wrote:
> >
> > > +#define parity(val) \
> > > +({
On Wed, Feb 26, 2025 at 10:29:11PM +, David Laight wrote:
> On Mon, 24 Feb 2025 14:27:03 -0500
> Yury Norov wrote:
>
> > +#define parity(val)\
> > +({ \
> > + u64 __v = (val);
On Thu, Feb 27, 2025 at 07:38:58AM +0100, Jiri Slaby wrote:
> On 26. 02. 25, 19:33, Yury Norov wrote:
> > > Not in cases where macros are inevitable. I mean, do we need parityXX()
> > > for
> > > XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for
> > > everybody?
> >
> > The exist
On 26. 02. 25, 19:33, Yury Norov wrote:
Not in cases where macros are inevitable. I mean, do we need parityXX() for
XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for everybody?
The existing codebase has something like:
int ret;
ret = i3c_master_get_free_addr(
On Mon, 24 Feb 2025 14:27:03 -0500
Yury Norov wrote:
> +#define parity(val) \
> +({ \
> + u64 __v = (val);\
> + int __ret; \
> +
On Wed, Feb 26, 2025 at 08:14:14AM +0100, Jiri Slaby wrote:
> On 25. 02. 25, 14:29, Kuan-Wei Chiu wrote:
> > > +#define parity(val) \
> > > +({ \
> > > + u64 __v = (val);\
> >
Hi Jiri,
On Wed, Feb 26, 2025 at 08:14:14AM +0100, Jiri Slaby wrote:
> On 25. 02. 25, 14:29, Kuan-Wei Chiu wrote:
> > > +#define parity(val) \
> > > +({ \
> > > + u64 __v = (val);
On 25. 02. 25, 14:29, Kuan-Wei Chiu wrote:
+#define parity(val)\
+({ \
+ u64 __v = (val);\
+ int __ret; \
+ switch (BITS_P
On February 25, 2025 1:43:27 PM PST, Andrew Cooper
wrote:
>> Incidentally, in all of this, didn't anyone notice __builtin_parity()?
>
>Yes. It it has done sane for a decade on x86, yet does things such as
>emitting a library call on other architectures.
>
>https://godbolt.org/z/6qG3noebq
>
>~And
> Incidentally, in all of this, didn't anyone notice __builtin_parity()?
Yes. It it has done sane for a decade on x86, yet does things such as
emitting a library call on other architectures.
https://godbolt.org/z/6qG3noebq
~Andrew
On February 24, 2025 5:34:31 AM PST, David Laight
wrote:
>On Mon, 24 Feb 2025 08:09:43 +0100
>Jiri Slaby wrote:
>
>> On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
>> > Several parts of the kernel open-code parity calculations using
>> > different methods. Add a generic parity64() helper implemented
On February 24, 2025 5:34:31 AM PST, David Laight
wrote:
>On Mon, 24 Feb 2025 08:09:43 +0100
>Jiri Slaby wrote:
>
>> On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
>> > Several parts of the kernel open-code parity calculations using
>> > different methods. Add a generic parity64() helper implemented
On Tue, Feb 25, 2025 at 09:29:51PM +0800, Kuan-Wei Chiu wrote:
> Hi Yury,
>
> On Mon, Feb 24, 2025 at 02:27:03PM -0500, Yury Norov wrote:
> > On Mon, Feb 24, 2025 at 12:42:02AM +0800, Kuan-Wei Chiu wrote:
> > > Several parts of the kernel open-code parity calculations using
> > > different methods
Hi Yury,
On Mon, Feb 24, 2025 at 02:27:03PM -0500, Yury Norov wrote:
> On Mon, Feb 24, 2025 at 12:42:02AM +0800, Kuan-Wei Chiu wrote:
> > Several parts of the kernel open-code parity calculations using
> > different methods. Add a generic parity64() helper implemented with the
> > same efficient a
On Mon, Feb 24, 2025 at 12:42:02AM +0800, Kuan-Wei Chiu wrote:
> Several parts of the kernel open-code parity calculations using
> different methods. Add a generic parity64() helper implemented with the
> same efficient approach as parity8().
No reason to add parity32() and parity64() in separate
On Mon, Feb 24, 2025 at 01:34:31PM +, David Laight wrote:
> On Mon, 24 Feb 2025 08:09:43 +0100
> Jiri Slaby wrote:
>
> > On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
> > > Several parts of the kernel open-code parity calculations using
> > > different methods. Add a generic parity64() helper im
On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
Several parts of the kernel open-code parity calculations using
different methods. Add a generic parity64() helper implemented with the
same efficient approach as parity8().
Co-developed-by: Yu-Chun Lin
Signed-off-by: Yu-Chun Lin
Signed-off-by: Kuan-W
Several parts of the kernel open-code parity calculations using
different methods. Add a generic parity64() helper implemented with the
same efficient approach as parity8().
Co-developed-by: Yu-Chun Lin
Signed-off-by: Yu-Chun Lin
Signed-off-by: Kuan-Wei Chiu
---
include/linux/bitops.h | 22 +++
On Mon, 24 Feb 2025 08:09:43 +0100
Jiri Slaby wrote:
> On 23. 02. 25, 17:42, Kuan-Wei Chiu wrote:
> > Several parts of the kernel open-code parity calculations using
> > different methods. Add a generic parity64() helper implemented with the
> > same efficient approach as parity8().
> >
> > Co-d
21 matches
Mail list logo
