public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
* [Bug target/61296] New: Excessive alignment in ix86_data_alignment @ 2014-05-23 16:49 hjl.tools at gmail dot com 2014-05-27 18:23 ` [Bug target/61296] " hjl.tools at gmail dot com ` (17 more replies) 0 siblings, 18 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-05-23 16:49 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 Bug ID: 61296 Summary: Excessive alignment in ix86_data_alignment Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target: x86 ix86_data_alignment was introduced by https://gcc.gnu.org/ml/gcc-patches/2000-06/msg00871.html It aligns struct larger than 32 bytes to 32 bytes. This change https://gcc.gnu.org/ml/gcc-patches/2001-03/msg01356.html aligns struct/union/array bigger than 16 bytes to 16 bytes, which causes PR 56564 and leads to DATA_ABI_ALIGNMENT. When OPT is false, ix86_data_alignment may return alignment bigger than ABI required. It happens when the references is bound to the current definition. It improves the performance when data can be accessed with the biggest alignment. If data is aligned bigger than the biggest alignment, we may not get performance benefit while wasting alignment padding. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com @ 2014-05-27 18:23 ` hjl.tools at gmail dot com 2014-05-30 16:52 ` hjl.tools at gmail dot com ` (16 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-05-27 18:23 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> --- The comdat definition needs to the biggest alignment generated by any compilers. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com 2014-05-27 18:23 ` [Bug target/61296] " hjl.tools at gmail dot com @ 2014-05-30 16:52 ` hjl.tools at gmail dot com 2014-06-11 16:38 ` hjl.tools at gmail dot com ` (15 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-05-30 16:52 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> --- After r199898, DATA_ALIGNMENT is only for optimization purposes. Align struct >= 64 bytes to 64 bytes may increase data size due to excessive alignment. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com 2014-05-27 18:23 ` [Bug target/61296] " hjl.tools at gmail dot com 2014-05-30 16:52 ` hjl.tools at gmail dot com @ 2014-06-11 16:38 ` hjl.tools at gmail dot com 2014-12-11 17:21 ` hubicka at gcc dot gnu.org ` (14 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-06-11 16:38 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> --- Comments for DATA_ALIGNMENT One use of this macro is to increase alignment of medium-size data to make it all fit in fewer cache lines. Another is to cause character arrays to be word-aligned so that `strcpy' calls that copy constants to character arrays can be done inline. was added by https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=ed45e834f305d1f2709bf200a13d5beebc2fcfee to improve x86 FP performance, which might be partially copied from CONSTANT_ALIGNMENT: https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=f7d6703c5d83fc9fb06246d6eb49e9b61098045c ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (2 preceding siblings ...) 2014-06-11 16:38 ` hjl.tools at gmail dot com @ 2014-12-11 17:21 ` hubicka at gcc dot gnu.org 2014-12-11 17:33 ` jakub at gcc dot gnu.org ` (13 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hubicka at gcc dot gnu.org @ 2014-12-11 17:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 Jan Hubicka <hubicka at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2014-12-11 CC| |hubicka at gcc dot gnu.org, | |jakub at redhat dot com, | |mliska at suse dot cz, | |rguenther at suse dot de Ever confirmed|0 |1 --- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> --- Confirmed. I think this is counts as a regression because the alignment slowly increased as SSE and AVX was added (and it is regression to pre-2001 compilers). We currently produce 5-15% bigger data sections than LLVM on Firefox/libreoffice. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (3 preceding siblings ...) 2014-12-11 17:21 ` hubicka at gcc dot gnu.org @ 2014-12-11 17:33 ` jakub at gcc dot gnu.org 2014-12-11 17:38 ` hjl.tools at gmail dot com ` (12 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: jakub at gcc dot gnu.org @ 2014-12-11 17:33 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 Jakub Jelinek <jakub at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> --- I doubt we can do anything about it though, decreasing DATA_ALIGNMENT would break backwards compatibility with older gcc versions. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (4 preceding siblings ...) 2014-12-11 17:33 ` jakub at gcc dot gnu.org @ 2014-12-11 17:38 ` hjl.tools at gmail dot com 2014-12-11 23:25 ` jakub at gcc dot gnu.org ` (11 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-11 17:38 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jakub Jelinek from comment #5) > I doubt we can do anything about it though, decreasing DATA_ALIGNMENT would > break backwards compatibility with older gcc versions. We need a testcase to verify the claim. If it is true, GCC is incompatible with ICC nor LLVM. We aren't conform to psABI. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (5 preceding siblings ...) 2014-12-11 17:38 ` hjl.tools at gmail dot com @ 2014-12-11 23:25 ` jakub at gcc dot gnu.org 2014-12-16 13:21 ` hjl.tools at gmail dot com ` (10 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: jakub at gcc dot gnu.org @ 2014-12-11 23:25 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- See discussions when I've added DATA_ABI_ALIGNMENT. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (6 preceding siblings ...) 2014-12-11 23:25 ` jakub at gcc dot gnu.org @ 2014-12-16 13:21 ` hjl.tools at gmail dot com 2014-12-16 13:31 ` jakub at gcc dot gnu.org ` (9 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-16 13:21 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jakub Jelinek from comment #7) > See discussions when I've added DATA_ABI_ALIGNMENT. DATA_ABI_ALIGNMENT was added for PR 56564: /* Similar to DATA_ALIGNMENT, but for the cases where the ABI mandates some alignment increase, instead of optimization only purposes. E.g. AMD x86-64 psABI says that variables with array type larger than 15 bytes must be aligned to 16 byte boundaries. If this macro is not defined, then ALIGN is used. */ #define DATA_ABI_ALIGNMENT(TYPE, ALIGN) \ ix86_data_alignment ((TYPE), (ALIGN), false) and ix86_data_alignment was changed by https://gcc.gnu.org/ml/gcc-patches/2014-01/msg01086.html There is a discussion we should always align to DATA_ABI_ALIGNMENT: https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01435.html My question was "Should we limit DATA_ALIGNMENT to MAX (ABI alignment, natural alignment)?" GCC will only use the excessive alignment with locally defined data, which has no psABI implications: [hjl@gnu-6 pr61296]$ cat z.c struct foo { char i[128]; }; struct foo x = { 1 }; struct foo y = { 1 }; struct foo z = { 1 }; void bar () { int i; for (i = 0; i < sizeof (x.i); i++) x.i[i] = y.i[i] + z.i[i]; } [hjl@gnu-6 pr61296]$ /export/build/gnu/gcc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc/build-x86_64-linux/gcc/ -O3 -mavx2 -S z.c -fPIC [hjl@gnu-6 pr61296]$ cat z.s .file "z.c" .section .text.unlikely,"ax",@progbits .LCOLDB0: .text .LHOTB0: .p2align 4,,15 .globl bar .type bar, @function bar: .LFB0: .cfi_startproc leaq 8(%rsp), %r10 .cfi_def_cfa 10, 0 movq y@GOTPCREL(%rip), %rdi andq $-32, %rsp pushq -8(%r10) pushq %rbp .cfi_escape 0x10,0x6,0x2,0x76,0 movq %rsp, %rbp pushq %r12 pushq %r10 .cfi_escape 0xf,0x3,0x76,0x70,0x6 .cfi_escape 0x10,0xc,0x2,0x76,0x78 movq %rdi, %r10 pushq %rbx .cfi_escape 0x10,0x3,0x2,0x76,0x68 negq %r10 andl $31, %r10d je .L7 movq x@GOTPCREL(%rip), %r8 movq z@GOTPCREL(%rip), %r9 movl %r10d, %esi xorl %eax, %eax xorl %edx, %edx movl $128, %r11d .p2align 4,,10 .p2align 3 .L3: movzbl (%rdi,%rax), %ecx addl $1, %edx addb (%r9,%rax), %cl movb %cl, (%r8,%rax) movl %r11d, %ecx addq $1, %rax subl %edx, %ecx cmpl %r10d, %edx jne .L3 movl %edx, %eax movl %ecx, %ebx movl $96, %r11d movl $3, %r12d .L2: leaq (%r9,%rax), %rdx leaq (%rdi,%rax), %r10 addq %r8, %rax cmpl $4, %r12d vmovdqu (%rdx), %xmm0 vinserti128 $0x1, 16(%rdx), %ymm0, %ymm0 vpaddb (%r10), %ymm0, %ymm0 vmovups %xmm0, (%rax) vextracti128 $0x1, %ymm0, 16(%rax) vmovdqu 32(%rdx), %xmm0 vinserti128 $0x1, 48(%rdx), %ymm0, %ymm0 vpaddb 32(%r10), %ymm0, %ymm0 vmovups %xmm0, 32(%rax) vextracti128 $0x1, %ymm0, 48(%rax) vmovdqu 64(%rdx), %xmm0 vinserti128 $0x1, 80(%rdx), %ymm0, %ymm0 vpaddb 64(%r10), %ymm0, %ymm0 vmovups %xmm0, 64(%rax) vextracti128 $0x1, %ymm0, 80(%rax) jne .L4 vmovdqu 96(%rdx), %xmm0 vinserti128 $0x1, 112(%rdx), %ymm0, %ymm0 vpaddb 96(%r10), %ymm0, %ymm0 vmovups %xmm0, 96(%rax) vextracti128 $0x1, %ymm0, 112(%rax) .L4: leal (%r11,%rsi), %eax subl %r11d, %ecx cmpl %r11d, %ebx leal (%rax,%rcx), %esi je .L10 .p2align 4,,10 .p2align 3 .L5: movslq %eax, %rdx addl $1, %eax movzbl (%r9,%rdx), %ecx addb (%rdi,%rdx), %cl cmpl %esi, %eax movb %cl, (%r8,%rdx) jne .L5 .L10: vzeroupper popq %rbx popq %r10 .cfi_remember_state .cfi_def_cfa 10, 0 popq %r12 popq %rbp leaq -8(%r10), %rsp .cfi_def_cfa 7, 8 ret .p2align 4,,10 .p2align 3 .L7: .cfi_restore_state movl $128, %r11d movl $4, %r12d movl $128, %ebx xorl %eax, %eax movl $128, %ecx xorl %esi, %esi movq x@GOTPCREL(%rip), %r8 movq z@GOTPCREL(%rip), %r9 jmp .L2 .cfi_endproc .LFE0: .size bar, .-bar .section .text.unlikely .LCOLDE0: .text .LHOTE0: .globl z .data .align 64 .type z, @object .size z, 128 z: .byte 1 .zero 127 .globl y .align 64 .type y, @object .size y, 128 y: .byte 1 .zero 127 .globl x .align 64 .type x, @object .size x, 128 x: .byte 1 .zero 127 .ident "GCC: (GNU) 5.0.0 20141205 (experimental)" .section .note.GNU-stack,"",@progbits Do you have a testcase to show decreasing DATA_ALIGNMENT would break backwards compatibility with older gcc versions? Our data show that the excessive alignment doesn't improve performance. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (7 preceding siblings ...) 2014-12-16 13:21 ` hjl.tools at gmail dot com @ 2014-12-16 13:31 ` jakub at gcc dot gnu.org 2014-12-16 13:41 ` hjl.tools at gmail dot com ` (8 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: jakub at gcc dot gnu.org @ 2014-12-16 13:31 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to H.J. Lu from comment #8) > Do you have a testcase to show decreasing DATA_ALIGNMENT would break > backwards compatibility with older gcc versions? Older GCC versions used DATA_ALIGNMENT (what is now DATA_ABI_ALIGNMENT) on MEM_ALIGN etc., and gradually more and more optimizations relied on it, even when the data was defined in some other compilation unit or was comdat or could be interposed. See e.g. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564#c9 ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (8 preceding siblings ...) 2014-12-16 13:31 ` jakub at gcc dot gnu.org @ 2014-12-16 13:41 ` hjl.tools at gmail dot com 2014-12-16 13:47 ` jakub at gcc dot gnu.org ` (7 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-16 13:41 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #10 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jakub Jelinek from comment #9) > (In reply to H.J. Lu from comment #8) > > Do you have a testcase to show decreasing DATA_ALIGNMENT would break > > backwards compatibility with older gcc versions? > > Older GCC versions used DATA_ALIGNMENT (what is now DATA_ABI_ALIGNMENT) on > MEM_ALIGN etc., and gradually more and more optimizations relied on it, even > when the data was defined in some other compilation unit or was comdat or > could be interposed. See e.g. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56564#c9 I still don't see that limit DATA_ALIGNMENT to MAX (ABI alignment, natural alignment) will cause additional ABI problems which don't exist today. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (9 preceding siblings ...) 2014-12-16 13:41 ` hjl.tools at gmail dot com @ 2014-12-16 13:47 ` jakub at gcc dot gnu.org 2014-12-16 13:53 ` hjl.tools at gmail dot com ` (6 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: jakub at gcc dot gnu.org @ 2014-12-16 13:47 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> --- If you hit the assumption beyond what ABI mandates on some public symbol issue in some older GCC version, then sure, if you have that public symbol defined by ICC, it will misbehave. But, if it is compiled with current GCC without your proposed changes, it will work fine, newer GCCs don't assume anything beyond ABI mandates alignments, unless they control the definition and uses bind locally to it, but still align as optimization as much or more as older GCC used to align. With your proposed changes that would be no longer true. What is so hard to understand on it? ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (10 preceding siblings ...) 2014-12-16 13:47 ` jakub at gcc dot gnu.org @ 2014-12-16 13:53 ` hjl.tools at gmail dot com 2014-12-16 13:58 ` jakub at gcc dot gnu.org ` (5 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-16 13:53 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #12 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jakub Jelinek from comment #11) > If you hit the assumption beyond what ABI mandates on some public symbol > issue in some older GCC version, then sure, if you have that public symbol > defined by ICC, it will misbehave. But, if it is compiled with current GCC > without your proposed changes, it will work fine, newer GCCs don't assume > anything beyond ABI mandates alignments, unless they control the definition > and uses bind locally to it, but still align as optimization as much or more > as older GCC used to align. > With your proposed changes that would be no longer true. What is so hard to > understand on it? What is the maximum alignment the older GCCs may assume? ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (11 preceding siblings ...) 2014-12-16 13:53 ` hjl.tools at gmail dot com @ 2014-12-16 13:58 ` jakub at gcc dot gnu.org 2014-12-16 15:51 ` hjl.tools at gmail dot com ` (4 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: jakub at gcc dot gnu.org @ 2014-12-16 13:58 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> --- Read the sources? It really depends on many factors. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (12 preceding siblings ...) 2014-12-16 13:58 ` jakub at gcc dot gnu.org @ 2014-12-16 15:51 ` hjl.tools at gmail dot com 2014-12-16 19:24 ` hjl.tools at gmail dot com ` (3 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-16 15:51 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 H.J. Lu <hjl.tools at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kirill.yukhin at intel dot com --- Comment #14 from H.J. Lu <hjl.tools at gmail dot com> --- I got [hjl@gnu-6 pr61296]$ cat a.c struct foo { char i[128]; }; struct foo x = { 1 }; [hjl@gnu-6 pr61296]$ make a.s /export/build/gnu/gcc-misc/build-x86_64-linux/gcc/xgcc -B/export/build/gnu/gcc-misc/build-x86_64-linux/gcc/ -O3 -mavx2 -S a.c [hjl@gnu-6 pr61296]$ cat a.s .file "a.c" .globl x .data .align 64 .type x, @object .size x, 128 x: .byte 1 .zero 127 .ident "GCC: (GNU) 5.0.0 20141216 (experimental)" .section .note.GNU-stack,"",@progbits [hjl@gnu-6 pr61296]$ Which older GCC expects 64-byte alignment here? We should limit DATA_ALIGNMENT to the maximum alignment actually expected by the older GCC, which I believe is 32 byte, and have an option to limit DATA_ALIGNMENT to MAX (ABI alignment, natural alignment). ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (13 preceding siblings ...) 2014-12-16 15:51 ` hjl.tools at gmail dot com @ 2014-12-16 19:24 ` hjl.tools at gmail dot com 2014-12-17 14:23 ` hjl at gcc dot gnu.org ` (2 subsequent siblings) 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-16 19:24 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #15 from H.J. Lu <hjl.tools at gmail dot com> --- (In reply to Jakub Jelinek from comment #13) > Read the sources? It really depends on many factors. There are int max_align_compat = optimize_size ? BITS_PER_WORD : MIN (256, MAX_OFILE_ALIGNMENT); With -Os, we aren't compatible with the older GCC anyway. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (14 preceding siblings ...) 2014-12-16 19:24 ` hjl.tools at gmail dot com @ 2014-12-17 14:23 ` hjl at gcc dot gnu.org 2014-12-17 14:50 ` hjl.tools at gmail dot com 2021-09-12 7:47 ` pinskia at gcc dot gnu.org 17 siblings, 0 replies; 19+ messages in thread From: hjl at gcc dot gnu.org @ 2014-12-17 14:23 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 --- Comment #16 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> --- Author: hjl Date: Wed Dec 17 14:22:57 2014 New Revision: 218818 URL: https://gcc.gnu.org/viewcvs?rev=218818&root=gcc&view=rev Log: Add -malign-data={abi|compat|cachineline} Add -malign-data={abi|compat,cachineline} to control how GCC aligns variables. "compat" uses increased alignment value compatible with GCC 4.8 and earlier, "abi" uses alignment value as specified by the psABI, and "cacheline" uses increased alignment value to match the cache line size. "compat" is the default. gcc/ PR target/61296 * config/i386/i386-opts.h (ix86_align_data): New enum. * config/i386/i386.c (ix86_data_alignment): Return the ABI alignment value for -malign-data=abi, the cachine line size for -malign-data=cachineline and the older GCC compatible alignment value for for -malign-data=compat. * config/i386/i386.opt (malign-data=): New. * doc/invoke.texi: Document -malign-data=. gcc/testsuite/ PR target/61296 * gcc.target/i386/pr61296-2.c: New. * gcc.target/i386/pr61296-2.c: Likewise. * gcc.target/i386/pr61296-3.c: Likewise. * gcc.target/i386/pr61296-4.c: Likewise. * gcc.target/i386/pr61296-5.c: Likewise. * gcc.target/i386/pr61296-6.c: Likewise. * gcc.target/i386/pr61296-7.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/pr61296-1.c trunk/gcc/testsuite/gcc.target/i386/pr61296-2.c trunk/gcc/testsuite/gcc.target/i386/pr61296-3.c trunk/gcc/testsuite/gcc.target/i386/pr61296-4.c trunk/gcc/testsuite/gcc.target/i386/pr61296-5.c trunk/gcc/testsuite/gcc.target/i386/pr61296-6.c trunk/gcc/testsuite/gcc.target/i386/pr61296-7.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386-opts.h trunk/gcc/config/i386/i386.c trunk/gcc/config/i386/i386.opt trunk/gcc/doc/invoke.texi trunk/gcc/testsuite/ChangeLog ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (15 preceding siblings ...) 2014-12-17 14:23 ` hjl at gcc dot gnu.org @ 2014-12-17 14:50 ` hjl.tools at gmail dot com 2021-09-12 7:47 ` pinskia at gcc dot gnu.org 17 siblings, 0 replies; 19+ messages in thread From: hjl.tools at gmail dot com @ 2014-12-17 14:50 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 H.J. Lu <hjl.tools at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |5.0 --- Comment #17 from H.J. Lu <hjl.tools at gmail dot com> --- Fixed in GCC 5. ^ permalink raw reply [flat|nested] 19+ messages in thread
* [Bug target/61296] Excessive alignment in ix86_data_alignment 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com ` (16 preceding siblings ...) 2014-12-17 14:50 ` hjl.tools at gmail dot com @ 2021-09-12 7:47 ` pinskia at gcc dot gnu.org 17 siblings, 0 replies; 19+ messages in thread From: pinskia at gcc dot gnu.org @ 2021-09-12 7:47 UTC (permalink / raw) To: gcc-bugs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61296 Andrew Pinski <pinskia at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |drepper.fsp at gmail dot com --- Comment #19 from Andrew Pinski <pinskia at gcc dot gnu.org> --- *** Bug 54167 has been marked as a duplicate of this bug. *** ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-09-12 7:47 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-05-23 16:49 [Bug target/61296] New: Excessive alignment in ix86_data_alignment hjl.tools at gmail dot com 2014-05-27 18:23 ` [Bug target/61296] " hjl.tools at gmail dot com 2014-05-30 16:52 ` hjl.tools at gmail dot com 2014-06-11 16:38 ` hjl.tools at gmail dot com 2014-12-11 17:21 ` hubicka at gcc dot gnu.org 2014-12-11 17:33 ` jakub at gcc dot gnu.org 2014-12-11 17:38 ` hjl.tools at gmail dot com 2014-12-11 23:25 ` jakub at gcc dot gnu.org 2014-12-16 13:21 ` hjl.tools at gmail dot com 2014-12-16 13:31 ` jakub at gcc dot gnu.org 2014-12-16 13:41 ` hjl.tools at gmail dot com 2014-12-16 13:47 ` jakub at gcc dot gnu.org 2014-12-16 13:53 ` hjl.tools at gmail dot com 2014-12-16 13:58 ` jakub at gcc dot gnu.org 2014-12-16 15:51 ` hjl.tools at gmail dot com 2014-12-16 19:24 ` hjl.tools at gmail dot com 2014-12-17 14:23 ` hjl at gcc dot gnu.org 2014-12-17 14:50 ` hjl.tools at gmail dot com 2021-09-12 7:47 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).