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 <jbeul...@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
