On 05/06/2017 09:20 AM, Uros Bizjak wrote:
On Tue, Apr 18, 2017 at 8:30 PM, Denys Vlasenko wrote:
2017-04-18 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config
On 04/18/2017 08:30 PM, Denys Vlasenko wrote:
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
Ping.
nctions=N.
No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2017-04-18 Denys Vlasenko
* doc/invo
2017-04-18 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.
Index: gcc/common/config/i386/i386-common.c
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
The new SUBALIGN_LOG define will be used by the next patch.
While we are here, avoid generating ".p2align N,,2^N-1" -
it is functionally equivalent to ".p2align N". In this case, use
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
An extended explanation is in commit message of patch 3.
The test program:
int g();
int f(int i) {
i *= 3;
while (--i > 100) {
L1:if (g()) goto L1;
On 04/17/2017 09:54 PM, Sandra Loosemore wrote:
@item -falign-functions
@itemx -falign-functions=@var{n}
+@itemx -falign-functions=@var{n},@var{m}
+@itemx -falign-functions=@var{n},@var{m},@var{n2}
+@itemx -falign-functions=@var{n},@var{m},@var{n2},@var{m2}
@opindex falign-functions
Align
nctions=N.
No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2016-09-27 Denys Vlasenko
* doc/invo
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
The new SUBALIGN_LOG define will be used by the next patch.
While we are here, avoid generating ".p2align N,,2^N-1" -
it is functionally equivalent to ".p2align N". In this case, use
2016-09-27 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.
Index: gcc/common/config/i386/i386-common.c
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
An extended explanation is in commit message of patch 3.
The test program:
int g();
int f(int i) {
i *= 3;
while (--i > 100) {
L1:if (g()) goto L1;
nctions=N.
No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2016-09-27 Denys Vlasenko
* doc/invo
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
The test program:
int g();
int f(int i) {
i *= 3;
while (--i > 100) {
L1:if (g()) goto L1;
if (g()) goto L2;
}
return i
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
The new SUBALIGN_LOG define will be used by the next patch.
While we are here, avoid generating ".p2align N,,2^N-1" -
it is functionally equivalent to ".p2align N". In this case, use
2016-09-27 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.
Index: gcc/common/config/i386/i386-common.c
On 10/11/2016 10:14 PM, Bernd Schmidt wrote:
On 10/11/2016 04:23 PM, Denys Vlasenko wrote:
This is better than current behavior, but this is not what I want.
15-byte function does not need to be aligned to 16 bytes on a
machine with 128-byte L1I cachelines. It needs to be aligned to 128
bytes
On 10/11/2016 04:11 PM, Bernd Schmidt wrote:
Denys has submitted some patches to add more capabilities to the
-falign-* options, but these still have some issues, and the original
ideas seems to have been to allow for large alignments without
over-aligning small functions. The following patch i
On 10/06/2016 11:47 AM, Bernd Schmidt wrote:
On 09/30/2016 07:54 PM, Denys Vlasenko wrote:
+struct target_flag_state {
+ /* Each falign-foo can generate up to two levels of alignment:
+ -falign-foo=N,M[,N2,M2] */
+ struct align_flags x_align_loops[2];
+ struct align_flags x_align_jumps
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
The new SUBALIGN_LOG define will be used by the next patch.
While we are here, avoid generating ".p2align N,,2^N-1" -
it is functionally equivalent to ".p2align N". In this case, use
nctions=N.
No change from past behavior:
Tested that "-falign-functions" uses an arch-dependent alignment.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2016-09-27 Denys Vlasenko
* doc/invo
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
The test program:
int g();
int f(int i) {
i *= 3;
while (--i > 100) {
L1:if (g()) goto L1;
if (g()) goto L2;
}
return i
2016-09-27 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.
Index: gcc/common/config/i386/i386-common.c
On 09/30/2016 01:20 PM, Bernd Schmidt wrote:
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
- /* Comes from final.c -- no real reason to change it. */
-#define MAX_CODE_ALIGN 16
-
case
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
+#ifdef SUBALIGN_LOG
We want to avoid adding new #defines; existing ones are being converted
to target hooks. I suspect the best way is to record whether an M value
was specified, and override it in the x86 option_override if required.
If that&#
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
No change from past behavior: Tested that "-falign-functions" uses
an arch-dependent alignment. Tested that "-O2" uses an
arch-dependent alignment. Tested that "-O2 -falign-fun
nt.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2016-09-27 Denys Vlasenko
* common.opt (-falign-functions=): Accept a string instead of integer.
(-falign-jumps=): Likewise.
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
This is version 4 of the patch set. Changes since version 3:
* Improved documentation in invoke.texi
* Fixed x86-specific calculation of default N2 value:
previous version was d
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
The new SUBALIGN_LOG define will be used by the next patch.
2016-09-27 Denys Vlasenko
* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignmen
On 09/27/2016 01:53 PM, Bernd Schmidt wrote:
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
nt.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2016-09-26 Denys Vlasenko
* common.opt (-falign-functions=): Accept a string instead of integer.
(-falign-jumps=): Likewise.
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
2016-09-26 Denys Vlasenko
* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignment" code.
* config/i386/gnu-user.h (ASM_OUTPUT_MAX_SKIP_
nt.
Tested that "-O2" uses an arch-dependent alignment.
Tested that "-O2 -falign-functions=N" uses explicitly given alignment.
2016-08-30 Denys Vlasenko
* common.opt (-falign-functions=): Accept a string instead of integer.
(-falign-jumps=): Likewise.
align 3" is not emitted.
This behavior will be implemented differently by the next patch.
2016-08-30 Denys Vlasenko
* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignment" code.
* config/i386/gnu-user.h (ASM_OUTPUT_MAX_SKIP_
On 08/15/2016 03:30 PM, Richard Biener wrote:
On Mon, Aug 15, 2016 at 1:53 PM, Denys Vlasenko wrote:
On 08/15/2016 11:45 AM, Richard Biener wrote:
Thus. For this CPU, alignment of loops to 8 bytes is wrong: it helps if
it
happens
to align a loop to 16 bytes, but it may in fact hurt
On 08/15/2016 11:45 AM, Richard Biener wrote:
Thus. For this CPU, alignment of loops to 8 bytes is wrong: it helps if it
happens
to align a loop to 16 bytes, but it may in fact hurt performance if it
happens to align
a loop to 16+8 bytes and this pushes loop's body end over the next 16-byte
bound
On 08/12/2016 05:20 PM, Denys Vlasenko wrote:
Yes, I know all that. Fetching is one thing. Loop cache is for instance
another (more important) thing. Not aligning the loop head increases
chance of the whole loop being split over more cache lines than necessary.
Jump predictors also don&#
Testing:
tested that with -falign-functions=N (tried 8, 15, 16, 17...) the alignment
directives are the same before and after the patch.
Tested that -falign-functions=N,N (two equal paramenters) works exactly
like -falign-functions=N.
2016-08-12 Denys Vlasenko
* common.opt (-falign-functi
yBridge CPU did not reveal any performance difference
for a tight loop which starts at byte 7 inside 64-byte cacheline,
and the same loop at byte 8.
2016-08-12 Denys Vlasenko
* config/i386/freebsd.h (ASM_OUTPUT_MAX_SKIP_ALIGN): Remove "If N
is large, do at least 8 byte alignment&
On 08/12/2016 04:28 PM, Michael Matz wrote:
Hi,
On Fri, 12 Aug 2016, Denys Vlasenko wrote:
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
On 08/12/2016 04:00 PM, Michael Matz wrote:
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
On 08/11/2016 10:59 PM, Andrew Pinski wrote:
On Thu, Aug 11, 2016 at 1:49 PM, Denys Vlasenko wrote:
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment
runs fastest (he tried many other possibilites).
However, developers are
On 08/11/2016 10:49 PM, Denys Vlasenko wrote:
falign-functions=N is too simplistic.
This change makes it possible to align function to 64-byte boundaries *IF*
this does not introduce huge amount of padding.
This is my first submission to gcc-patches@gcc.gnu.org
Please let me know if my patch
falign-functions=N is too simplistic.
Ingo Molnar ran some tests and it looks on latest x86 CPUs, 64-byte alignment
runs fastest (he tried many other possibilites).
However, developers are less than thrilled by the idea of a slam-dunk 64-byte
aligning everything. Too much waste:
On 05/20/
43 matches
Mail list logo
