This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding
- From: Michael Matz <matz at suse dot de>
- To: Denys Vlasenko <dvlasenk at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 12 Aug 2016 16:00:54 +0200 (CEST)
- Subject: Re: [PATCH] Extend -falign-FOO=N to N[,M]: the second number is max padding
- Authentication-results: sourceware.org; auth=none
- References: <20160811204900.15846-1-dvlasenk@redhat.com>
Hi,
On Thu, 11 Aug 2016, Denys Vlasenko wrote:
> This change makes it possible to align function to 64-byte boundaries
> *IF* this does not introduce huge amount of padding.
>
> Patch drops forced alignment to 8 if requested alignment is higher than
> 8: before the patch, -falign-functions=9 was generating
>
> .p2align 4,,8
> .p2align 3
>
> which means: "align to 16 if the skip is 8 bytes or less; else align to 8".
> After this change, ".p2align 3" is not emitted.
>
> It is dropped because I ultimately want to do something like
> -falign-functions=64,8 - IOW, I want to align functions to 64 bytes, but
> only if that generates padding of less than 8 bytes - otherwise I want
> *no alignment at all*.
Have you tested the performance impact of your patch? Note that the macro
you changed is used for function and code label alignment. So, unless I
misunderstand something that means that if the large alignment can't be
achieved for e.g. a loop start label, you won't align it at all anymore.
This should be fairly catastrophic for any loopy benchmark, so anything
like this would have to be checked on a couple benchmarks from cpu2000
(possibly cpu2006), which has some that are extremely alignment sensitive.
Even for function labels I'd find no alignment at all strange, and I don't
see why you'd want this.
> The forced ".p2align 3" interferes with that intention.
Well, yes, but _why_ don't you want 8 byte alignment if 64-byte can't be
achieved?
Ciao,
Michael.