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)
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.
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
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.
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
© 2016 - 2025 Red Hat, Inc.