[PATCH] x86: don't have gcc over-align data

[PATCH] x86: don't have gcc over-align data

[Jan Beulich]

For (aiui) backwards compatibility reasons, gcc defaults to a mode that
was the exclusive one up to gcc4.8, establishing 32-byte alignment for
aggregates larger than a certain size. We don't rely on such, and hence
we can do with the psABI-compliant 16-byte alignment.

Savings in the build I'm looking at:
- .data.ro_after_init		 344 bytes
- .rodata + .data.rel.ro	1904 bytes
- .init.*data.cf_clobber	 232 bytes
- .init (overall)		 688 bytes
- .data.read_mostly		 864 bytes
- .data				 600 bytes
- .bss				1472 bytes

Overall xen-syms' _end happens to move down there by 2 pages.

Clang doesn't support the option, presumably because they never over-
aligned data.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/x86/arch.mk
+++ b/xen/arch/x86/arch.mk
@@ -8,6 +8,9 @@ CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFF
 # Prevent floating-point variables from creeping into Xen.
 CFLAGS += -msoft-float
 
+# Don't needlessly over-align larger aggregates.
+CFLAGS-$(CONFIG_CC_IS_GCC) += -malign-data=abi
+
 $(call cc-options-add,CFLAGS,CC,$(EMBEDDED_EXTRA_CFLAGS))
 $(call cc-option-add,CFLAGS,CC,-Wnested-externs)
 $(call as-option-add,CFLAGS,CC,".equ \"x\"$(comma)1",-DHAVE_AS_QUOTED_SYM)

Re: [PATCH] x86: don't have gcc over-align data

[Jan Beulich]

On 25.06.2025 11:04, Jan Beulich wrote:
> For (aiui) backwards compatibility reasons, gcc defaults to a mode that
> was the exclusive one up to gcc4.8, establishing 32-byte alignment for

Correction - it's 16- or 32-byte alignment, depending on size.

> aggregates larger than a certain size. We don't rely on such, and hence
> we can do with the psABI-compliant 16-byte alignment.
> 
> Savings in the build I'm looking at:
> - .data.ro_after_init		 344 bytes
> - .rodata + .data.rel.ro	1904 bytes
> - .init.*data.cf_clobber	 232 bytes
> - .init (overall)		 688 bytes
> - .data.read_mostly		 864 bytes
> - .data				 600 bytes
> - .bss				1472 bytes
> 
> Overall xen-syms' _end happens to move down there by 2 pages.
> 
> Clang doesn't support the option, presumably because they never over-
> aligned data.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>

Looks like this is becoming a necessary pre-req to "vpci: Refactor
REGISTER_VPCI_INIT" [1], unless we want to use undesirable workarounds
or hackery there [2]. Hence may I ask for feedback here?

Thanks, Jan

[1] https://lists.xen.org/archives/html/xen-devel/2025-06/msg00840.html
[2] https://lists.xen.org/archives/html/xen-devel/2025-06/msg01760.html

Re: [PATCH] x86: don't have gcc over-align data

[Roger Pau Monné]

On Wed, Jun 25, 2025 at 11:04:14AM +0200, Jan Beulich wrote:
> For (aiui) backwards compatibility reasons, gcc defaults to a mode that
> was the exclusive one up to gcc4.8, establishing 32-byte alignment for
> aggregates larger than a certain size. We don't rely on such, and hence
> we can do with the psABI-compliant 16-byte alignment.
> 
> Savings in the build I'm looking at:
> - .data.ro_after_init		 344 bytes
> - .rodata + .data.rel.ro	1904 bytes
> - .init.*data.cf_clobber	 232 bytes
> - .init (overall)		 688 bytes
> - .data.read_mostly		 864 bytes
> - .data				 600 bytes
> - .bss				1472 bytes
> 
> Overall xen-syms' _end happens to move down there by 2 pages.
> 
> Clang doesn't support the option, presumably because they never over-
> aligned data.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/x86/arch.mk
> +++ b/xen/arch/x86/arch.mk
> @@ -8,6 +8,9 @@ CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFF
>  # Prevent floating-point variables from creeping into Xen.
>  CFLAGS += -msoft-float
>  
> +# Don't needlessly over-align larger aggregates.
> +CFLAGS-$(CONFIG_CC_IS_GCC) += -malign-data=abi

Instead of using CONFIG_CC_IS_GCC should be just use cc-option-add to
check for the option begin present, regardless of the underlying
compiler?

Thanks, Roger.

Re: [PATCH] x86: don't have gcc over-align data

[Jan Beulich]

On 21.07.2025 16:48, Roger Pau Monné wrote:
> On Wed, Jun 25, 2025 at 11:04:14AM +0200, Jan Beulich wrote:
>> For (aiui) backwards compatibility reasons, gcc defaults to a mode that
>> was the exclusive one up to gcc4.8, establishing 32-byte alignment for
>> aggregates larger than a certain size. We don't rely on such, and hence
>> we can do with the psABI-compliant 16-byte alignment.
>>
>> Savings in the build I'm looking at:
>> - .data.ro_after_init		 344 bytes
>> - .rodata + .data.rel.ro	1904 bytes
>> - .init.*data.cf_clobber	 232 bytes
>> - .init (overall)		 688 bytes
>> - .data.read_mostly		 864 bytes
>> - .data				 600 bytes
>> - .bss				1472 bytes
>>
>> Overall xen-syms' _end happens to move down there by 2 pages.
>>
>> Clang doesn't support the option, presumably because they never over-
>> aligned data.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/x86/arch.mk
>> +++ b/xen/arch/x86/arch.mk
>> @@ -8,6 +8,9 @@ CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFF
>>  # Prevent floating-point variables from creeping into Xen.
>>  CFLAGS += -msoft-float
>>  
>> +# Don't needlessly over-align larger aggregates.
>> +CFLAGS-$(CONFIG_CC_IS_GCC) += -malign-data=abi
> 
> Instead of using CONFIG_CC_IS_GCC should be just use cc-option-add to
> check for the option begin present, regardless of the underlying
> compiler?

We could do so, but why would we want to, when all gcc versions we support
know of the option and Clang has never had a need for it? cc-option-add
is more overhead, and I think we want to avoid such, even if each individual
instance contributes only a tiny bit to overall build time.

Jan

Re: [PATCH] x86: don't have gcc over-align data

[Roger Pau Monné]

On Mon, Jul 21, 2025 at 06:05:22PM +0200, Jan Beulich wrote:
> On 21.07.2025 16:48, Roger Pau Monné wrote:
> > On Wed, Jun 25, 2025 at 11:04:14AM +0200, Jan Beulich wrote:
> >> For (aiui) backwards compatibility reasons, gcc defaults to a mode that
> >> was the exclusive one up to gcc4.8, establishing 32-byte alignment for
> >> aggregates larger than a certain size. We don't rely on such, and hence
> >> we can do with the psABI-compliant 16-byte alignment.
> >>
> >> Savings in the build I'm looking at:
> >> - .data.ro_after_init		 344 bytes
> >> - .rodata + .data.rel.ro	1904 bytes
> >> - .init.*data.cf_clobber	 232 bytes
> >> - .init (overall)		 688 bytes
> >> - .data.read_mostly		 864 bytes
> >> - .data				 600 bytes
> >> - .bss				1472 bytes
> >>
> >> Overall xen-syms' _end happens to move down there by 2 pages.
> >>
> >> Clang doesn't support the option, presumably because they never over-
> >> aligned data.
> >>
> >> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> >>
> >> --- a/xen/arch/x86/arch.mk
> >> +++ b/xen/arch/x86/arch.mk
> >> @@ -8,6 +8,9 @@ CFLAGS += -DXEN_IMG_OFFSET=$(XEN_IMG_OFF
> >>  # Prevent floating-point variables from creeping into Xen.
> >>  CFLAGS += -msoft-float
> >>  
> >> +# Don't needlessly over-align larger aggregates.
> >> +CFLAGS-$(CONFIG_CC_IS_GCC) += -malign-data=abi
> > 
> > Instead of using CONFIG_CC_IS_GCC should be just use cc-option-add to
> > check for the option begin present, regardless of the underlying
> > compiler?
> 
> We could do so, but why would we want to, when all gcc versions we support
> know of the option and Clang has never had a need for it? cc-option-add
> is more overhead, and I think we want to avoid such, even if each individual
> instance contributes only a tiny bit to overall build time.

IIRC we only evaluate those once now, so the overhead would be
minimal.

Regardless:

Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>

Thanks, Roger.