On 09/26/2016 09:08 PM, Denys Vlasenko wrote:
+@gccoptlist{-faggressive-loop-optimizations @gol
+-falign-functions[=@var{n}[,@var{m},[@var{n}[,@var{m}]]]] @gol
+-falign-jumps[=@var{n}[,@var{m}]] @gol
+-falign-labels[=@var{n}[,@var{m}]] -falign-loops[=@var{n}[,@var{m}]] @gol
@itemx -falign-functions=@var{n}
+@itemx -falign-functions=@var{n},@var{m}
@opindex falign-functions
+If @var{m} is not specified, it defaults to @var{n}.
There are inconsistencies here about how many arguments these take.
There's no documentation of what it would mean to have more than two.
The first paragraph seems to imply it's only allowed for
-falign-functions, but the same implementation is used for all three.
+#if defined (__i386__) || defined (__x86_64__)
+ /* Before -falign-foo=N,M,N2,M2 was introduced, x86 had a tweak.
+ -falign-functions=N with N > 8 was adding secondary alignment.
+ -falign-functions=10 was emitting this before every function:
+ .p2align 4,,9
+ .p2align 3
+ Now this behavior (and more) can be explicitly requested:
+ -falign-functions=16,10,8
+ Retain old behavior if N2 is missing: */
+ else if (a[0].log > 3)
+ a[1].log = 3;
+#endif
Can't have such #ifdef blocks in generic code. To start with, this
changes behaviour based on the host, when you want it to change
depending on the target. If there's no way to detect such a situation
from the x86 backend, such as in the option_override function, then
you'll need a hook.
IIUC the intention for the whole patch is that behaviour is unchanged by
default, but there are additional options for users to choose?
Since it seems this is mostly for x86, maybe Uros should have a say in
whether this patch is a good idea or not. Maybe it would be good to also
pursue the idea of taking function size into account?
Bernd
