public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Igor Zamyatin <izamyatin@gmail.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	Jakub Jelinek <jakub@redhat.com>
Subject: Re: FW: [PATCH] DATA_ALIGNMENT vs. DATA_ABI_ALIGNMENT (PR target/56564)
Date: Wed, 19 Jun 2013 07:02:00 -0000	[thread overview]
Message-ID: <CAKdSQZ=Uk=P3LvL6FW4tpyQy6AbbnyOSn5J5Y9eVLjaoFab1tw@mail.gmail.com> (raw)
In-Reply-To: <0EFAB2BDD0F67E4FB6CCC8B9F87D75692B5204DB@IRSMSX101.ger.corp.intel.com>

The change also affects vectorizer in avx case which could be seen for
gcc.dg/tree-ssa/loop-19.c test.

After the change report says

loop-19_bad.c:16: note: === vect_analyze_data_refs_alignment ===
loop-19_bad.c:16: note: vect_compute_data_ref_alignment:
loop-19_bad.c:16: note: can't force alignment of ref: a[j_9]
loop-19_bad.c:16: note: vect_compute_data_ref_alignment:
loop-19_bad.c:16: note: can't force alignment of ref: c[j_9]

AFAICS first condition in ix86_data_alignment was true before the
change so 256 was a return value.

Do we need to tweak this test also?

Thanks,
Igor

> Hi!
>
> This PR is about DATA_ALIGNMENT macro increasing alignment of some decls for optimization purposes beyond ABI mandated levels.  It is fine to emit the vars aligned as much as we want for optimization purposes, but if we can't be sure that references to that decl bind to the definition we increased the alignment on (e.g. common variables, or -fpic code without hidden visibility, weak vars etc.), we can't assume that alignment.
> As DECL_ALIGN is used for both the alignment emitted for the definitions and alignment assumed on code referring to it, this patch increases DECL_ALIGN only on decls where decl_binds_to_current_def_p is true, and otherwise the optimization part on top of that emits only when aligning definition.
> On x86_64, DATA_ALIGNMENT macro was partly an optimization, partly ABI mandated alignment increase, so I've introduced a new macro, DATA_ABI_ALIGNMENT, which is the ABI mandated increase only (on x86-64 I think the only one is that arrays with size 16 bytes or more (and VLAs, but that is not handled by DATA*ALIGNMENT) are at least 16 byte aligned).
>
> Bootstrapped/regtested on x86_64-linux and i686-linux.  No idea about other targets, I've kept them all using DATA_ALIGNMENT, which is considered optimization increase only now, if there is some ABI mandated alignment increase on other targets, that should be done in DATA_ABI_ALIGNMENT as well as DATA_ALIGNMENT.  The patch causes some vectorization regressions (tweaked in the testsuite), especially for common vars where we used to align say common arrays to 256 bits rather than the ABI mandated 128 bits, or for -fpic code, but I'm afraid we need to live with that, if you compile another file with say icc or some other compiler which doesn't increase alignment beyond ABI mandated level and that other file defines the var say as non-common, we have wrong-code.
>
> 2013-06-07  Jakub Jelinek  <jakub@redhat.com>
>
>         PR target/56564
>         * varasm.c (align_variable): Don't use DATA_ALIGNMENT or
>         CONSTANT_ALIGNMENT if !decl_binds_to_current_def_p (decl).
>         Use DATA_ABI_ALIGNMENT for that case instead if defined.
>         (get_variable_align): New function.
>         (get_variable_section, emit_bss, emit_common,
>         assemble_variable_contents, place_block_symbol): Use
>         get_variable_align instead of DECL_ALIGN.
>         (assemble_noswitch_variable): Add align argument, use it
>         instead of DECL_ALIGN.
>         (assemble_variable): Adjust caller.  Use get_variable_align
>         instead of DECL_ALIGN.
>         * config/i386/i386.h (DATA_ALIGNMENT): Adjust x86_data_alignment
>         caller.
>         (DATA_ABI_ALIGNMENT): Define.
>         * config/i386/i386-protos.h (x86_data_alignment): Adjust prototype.
>         * config/i386/i386.c (x86_data_alignment): Add opt argument.  If
>         opt is false, only return the psABI mandated alignment increase.
>         * doc/tm.texi.in (DATA_ABI_ALIGNMENT): Document.
>         * doc/tm.texi: Regenerated.
>
>         * gcc.target/i386/pr56564-1.c: New test.
>         * gcc.target/i386/pr56564-2.c: New test.
>         * gcc.target/i386/pr56564-3.c: New test.
>         * gcc.target/i386/pr56564-4.c: New test.
>         * gcc.target/i386/avx256-unaligned-load-4.c: Add -fno-common.
>         * gcc.target/i386/avx256-unaligned-store-1.c: Likewise.
>         * gcc.target/i386/avx256-unaligned-store-3.c: Likewise.
>         * gcc.target/i386/avx256-unaligned-store-4.c: Likewise.
>         * gcc.target/i386/vect-sizes-1.c: Likewise.
>         * gcc.target/i386/memcpy-1.c: Likewise.
>         * gcc.dg/vect/costmodel/i386/costmodel-vect-31.c (tmp): Initialize.
>         * gcc.dg/vect/costmodel/x86_64/costmodel-vect-31.c (tmp): Likewise.
>

  parent reply	other threads:[~2013-06-19  7:02 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-07 19:26 Jakub Jelinek
2013-06-07 20:43 ` Richard Henderson
2013-06-07 21:14   ` Jakub Jelinek
2013-06-08 15:13     ` Jakub Jelinek
2013-06-10 14:52     ` Richard Henderson
2013-06-10 15:45       ` Jakub Jelinek
2013-06-10 19:44         ` David Edelsohn
2013-06-11  0:44         ` DJ Delorie
2013-06-11  6:06           ` Jakub Jelinek
2013-06-11 15:20             ` DJ Delorie
2013-06-07 22:56   ` Hans-Peter Nilsson
2013-06-08 15:05     ` Jakub Jelinek
2013-06-10 10:51   ` Bernd Schmidt
2013-06-10 10:56     ` Jakub Jelinek
2013-06-10 11:03       ` Bernd Schmidt
2013-06-10 11:52   ` Ulrich Weigand
2013-06-12 17:52   ` Edmar Wienskoski
2013-06-13  7:41     ` Alan Modra
2013-06-13 15:37       ` Alan Modra
2013-06-13 15:42         ` Jakub Jelinek
2013-06-13 22:48           ` Alan Modra
2013-06-14  9:00             ` Jakub Jelinek
2013-06-14 10:42               ` Alan Modra
2013-06-14 10:54                 ` Jakub Jelinek
2013-06-14 14:57                   ` Alan Modra
2013-06-17 23:37         ` David Edelsohn
     [not found] ` <0EFAB2BDD0F67E4FB6CCC8B9F87D75692B5204DB@IRSMSX101.ger.corp.intel.com>
2013-06-19  7:02   ` Igor Zamyatin [this message]
2013-06-19  7:05     ` FW: " Jakub Jelinek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKdSQZ=Uk=P3LvL6FW4tpyQy6AbbnyOSn5J5Y9eVLjaoFab1tw@mail.gmail.com' \
    --to=izamyatin@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).