[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v5 4/6] x86: control memset() and memcpy() inlining



Le 05/06/2025 à 12:28, Jan Beulich a écrit :
> Stop the compiler from inlining non-trivial memset() and memcpy() (for
> memset() see e.g. map_vcpu_info() or kimage_load_segments() for
> examples). This way we even keep the compiler from using REP STOSQ /
> REP MOVSQ when we'd prefer REP STOSB / REP MOVSB (when ERMS is
> available).
>

If the size is known and constant, and the compiler is able to generate
a trivial rep movs/stos (usually with a mov $x, %ecx before). I don't
see a reason to prevent it or forcing it to make a function call, as I
suppose it is very likely that the plain inline rep movs/stos will
perform better than a function call (even if it is not the prefered rep
movsb/stosb), eventually also being smaller.

I wonder if it is possible to only generate inline rep movs/stos for
"trivial cases" (i.e preceded with a plain mov $x, %ecx), and rely on
either inline movs or function call in other cases (non-trivial ones).

> With gcc10 this yields a modest .text size reduction (release build) of
> around 2k.
>
> Unfortunately these options aren't understood by the clang versions I
> have readily available for testing with; I'm unaware of equivalents.
>
> Note also that using cc-option-add is not an option here, or at least I
> couldn't make things work with it (in case the option was not supported
> by the compiler): The embedded comma in the option looks to be getting
> in the way.
>
> Requested-by: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v3: Re-base.
> v2: New.
> ---
> The boundary values are of course up for discussion - I wasn't really
> certain whether to use 16 or 32; I'd be less certain about using yet
> larger values.
>
> Similarly whether to permit the compiler to emit REP STOSQ / REP MOVSQ
> for known size, properly aligned blocks is up for discussion.
>
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -58,6 +58,9 @@ endif
>   $(call cc-option-add,CFLAGS_stack_boundary,CC,-mpreferred-stack-boundary=3)
>   export CFLAGS_stack_boundary
>
> +CFLAGS += $(call 
> cc-option,$(CC),-mmemcpy-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
> +CFLAGS += $(call 
> cc-option,$(CC),-mmemset-strategy=unrolled_loop:16:noalign$(comma)libcall:-1:noalign)
> +
>   ifeq ($(CONFIG_UBSAN),y)
>   # Don't enable alignment sanitisation.  x86 has efficient unaligned 
> accesses,
>   # and various things (ACPI tables, hypercall pages, stubs, etc) are 
> wont-fix.
>
>

Teddy


Teddy Astie | Vates XCP-ng Developer

XCP-ng & Xen Orchestra - Vates solutions

web: https://vates.tech





 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.