All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Andrew Cooper <andrew.cooper3@citrix.com>
Cc: "Roger Pau Monné" <roger.pau@citrix.com>, "Wei Liu" <wl@xen.org>,
	"Stefano Stabellini" <sstabellini@kernel.org>,
	"Julien Grall" <julien@xen.org>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>,
	"Michal Orzel" <michal.orzel@amd.com>,
	"Oleksii Kurochko" <oleksii.kurochko@gmail.com>,
	"Shawn Anastasio" <sanastasio@raptorengineering.com>,
	"consulting @ bugseng . com" <consulting@bugseng.com>,
	"Simone Ballarin" <simone.ballarin@bugseng.com>,
	"Federico Serafini" <federico.serafini@bugseng.com>,
	"Nicola Vetrini" <nicola.vetrini@bugseng.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 2/7] xen/bitops: Implement ffs() in common logic
Date: Thu, 14 Mar 2024 17:35:02 +0100	[thread overview]
Message-ID: <06cedbcc-fee9-4a58-a0bb-42f6b594ccf8@suse.com> (raw)
In-Reply-To: <6a3c09a1-f35f-4d1e-bbba-342388da71ef@citrix.com>

On 14.03.2024 17:23, Andrew Cooper wrote:
> On 14/03/2024 2:16 pm, Jan Beulich wrote:
>> On 13.03.2024 18:27, Andrew Cooper wrote:
>>> --- a/xen/arch/arm/include/asm/bitops.h
>>> +++ b/xen/arch/arm/include/asm/bitops.h
>>> @@ -157,7 +157,7 @@ static inline int fls(unsigned int x)
>>>  }
>>>  
>>>  
>>> -#define ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
>>> +#define arch_ffs(x) ({ unsigned int __t = (x); fls(ISOLATE_LSB(__t)); })
>> The way the macro is invoked, I don't think the helper local variable
>> is then needed anymore?
> 
> I strongly suspect It is still needed.  ISOLATE_LSB() double-expands its
> parameter.

Even that double evaluation doesn't matter when the invoking entity is an
inline function, and it doesn't use any non-trivial expression as argument.

>>> --- a/xen/include/xen/bitops.h
>>> +++ b/xen/include/xen/bitops.h
>>> @@ -110,6 +110,21 @@ static inline int generic_flsl(unsigned long x)
>>>  
>>>  #include <asm/bitops.h>
>>>  
>>> +/*
>>> + * Find First Set bit.  Bits are labelled from 1.
>>> + */
>>> +static always_inline __pure unsigned int ffs(unsigned int x)
>> Why always_inline?
> 
> For all the normal reasons to counter Clang and GCC doing stupid things
> with inlines that contain assembly.

Hmm, there are issues when the asm() would look "complex" to the compiler,
but that's not the case here. I was asking because, as you imply by how
you responded, we may need to gain many more always_inline when at some
time even you were arguing against overriding compiler decisions like this
(unless I'm mis-remembering).

Jan


  reply	other threads:[~2024-03-14 16:35 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-13 17:27 [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs() Andrew Cooper
2024-03-13 17:27 ` [PATCH 1/7] xen/bitops: Cleanup ahead of rearrangements Andrew Cooper
2024-03-13 18:39   ` Shawn Anastasio
2024-03-13 23:06   ` Andrew Cooper
2024-03-14 13:59   ` Jan Beulich
2024-03-13 17:27 ` [PATCH 2/7] xen/bitops: Implement ffs() in common logic Andrew Cooper
2024-03-14 14:16   ` Jan Beulich
2024-03-14 16:23     ` Andrew Cooper
2024-03-14 16:35       ` Jan Beulich [this message]
2024-03-13 17:27 ` [PATCH 3/7] xen/bitops: Implement ffsl() " Andrew Cooper
2024-03-13 17:48   ` Andrew Cooper
2024-03-14 13:45     ` Andrew Cooper
2024-03-13 18:16   ` Andrew Cooper
2024-03-13 17:27 ` [PATCH 4/7] xen/bitops: Delete generic_ffs{,l}() Andrew Cooper
2024-03-13 17:27 ` [PATCH 5/7] xen/bitops: Implement ffs64() in common logic Andrew Cooper
2024-03-14 15:56   ` Jan Beulich
2024-03-13 17:27 ` [PATCH 6/7] xen: Swap find_first_set_bit() for ffsl() - 1 Andrew Cooper
2024-03-14 14:30   ` Jan Beulich
2024-03-14 16:48     ` Oleksii
2024-03-14 16:55       ` Jan Beulich
2024-03-14 18:47     ` Andrew Cooper
2024-03-14 18:51       ` Andrew Cooper
2024-03-18  9:13         ` Jan Beulich
2024-03-18 12:27           ` Andrew Cooper
2024-03-13 17:27 ` [PATCH 7/7] xen/bitops: Delete find_first_set_bit() Andrew Cooper
2024-03-14 15:59   ` Jan Beulich
2024-03-14 17:14     ` Andrew Cooper
2024-03-15 13:48       ` Andrew Cooper
2024-03-15 14:16         ` Jan Beulich
2024-03-14 14:45 ` [RISCV] [PATCH 0/7] xen/bitops: Reduce the mess, starting with ffs() Andrew Cooper
2024-03-14 15:33   ` Jan Beulich
2024-03-14 15:55     ` Andrew Cooper
2024-03-14 16:32     ` Oleksii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=06cedbcc-fee9-4a58-a0bb-42f6b594ccf8@suse.com \
    --to=jbeulich@suse.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=consulting@bugseng.com \
    --cc=federico.serafini@bugseng.com \
    --cc=julien@xen.org \
    --cc=michal.orzel@amd.com \
    --cc=nicola.vetrini@bugseng.com \
    --cc=oleksii.kurochko@gmail.com \
    --cc=roger.pau@citrix.com \
    --cc=sanastasio@raptorengineering.com \
    --cc=simone.ballarin@bugseng.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.