On 30.07.2025 11:29, Andrew Cooper wrote:
> On 29/07/2025 3:44 pm, Jan Beulich wrote:
>> On 29.07.2025 16:29, Andrew Cooper wrote:
>>> On 29/07/2025 3:26 pm, Jan Beulich wrote:
>>>> This was needed only for generic_swap(), which disappeared in
>>>> 8cb0341a61fa ("xen/sort: Switch to an extern inline implementation").
>>>>
>>>> Signed-off-by: Jan Beulich <jbeul...@suse.com>
>>> Oh, nice.
>>>
>>> Acked-by: Andrew Cooper <andrew.coop...@citrix.com>
>> Thanks.
>>
>>> I'd expect there to be no change in generated code here, as everything
>>> gets inlined.
>> Not really, no. With the change in place, both gcc7 and gcc14 consider the
>> inlining of swap_ex() (in x86'es extable.c) as less beneficial, and hence
>> (like cmp_ex()) an out-of-line function appears, while overall code size
>> reduces. I expect that's because inlining decisions are taken based on
>> some intermediate internal representation rather than based on the code
>> that would ultimately be generated. And that intermediate internal
>> representation now changes, resulting in less of a win by doing the
>> inlining.
>
> Hmm. We might consider __always_inline,
I would actually expect a compiler to oppose to an always-inline function
to have its address taken.
> although it seems like gcc12
> does decide to inline them with this patch as-is.
Interesting how things can move back and forth between versions ...
Jan
