public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/57955] [4.8/4.9/5 Regression] Uniquization of constants reduces alignment of initializers
Date: Thu, 19 Feb 2015 14:26:00 -0000	[thread overview]
Message-ID: <bug-57955-4-3eRoMAO24s@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-57955-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57955

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, it seems the .LC0 VAR_DECL that is newly created undergoes
DATA_ABI_ALIGNMENT, DATA_ALIGNMENT and CONSTANT_ALIGNMENT treatment, but the
rs6000 backend doesn't consider it worthwhile to bump the alignment.
Old gimplify used to bump the alignment for the ctors to the alignment of the
var being initialized:
                new_tree = create_tmp_var_raw (type, "C");

                gimple_add_tmp_var (new_tree);
                TREE_STATIC (new_tree) = 1;
                TREE_READONLY (new_tree) = 1;
                DECL_INITIAL (new_tree) = ctor;
                if (align > DECL_ALIGN (new_tree))
                  {
                    DECL_ALIGN (new_tree) = align;
                    DECL_USER_ALIGN (new_tree) = 1;
                  }
which is definitely very excessive (128-byte alignment is bigger than
MAX_ALIGNMENT and hardly useful here).
I'd say if you think this is worth doing anything at all, then the best choice
might be to increase CONSTANT_ALIGNMENT for initializers larger than say 128
bits to 128 bits if Altivec or VSX is enabled - in current GCCs
CONSTANT_ALIGNMENT should be assumed only for decls that bind to the current
def, so the macro should be a pure optimization thing rather than an ABI thing,
only tweaking CONSTANT_ALIGNMENT would actually affect code that doesn't use
explicit align attribute on the vars.
The other possibility is to pass an extra align argument to
tree_output_constant_def and build_constant_def, that, if non-0, could bump
alignment of the created decl to what the caller would prefer to see.
We certainly should max that to BIGGEST_ALIGNMENT though, and in any case
wouldn't guarantee it, because the constant might have been already found in
the constant pool and at that point it has rtl created and it is too late for
bumping alignment.


  parent reply	other threads:[~2015-02-19 14:26 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-22 21:38 [Bug middle-end/57955] New: Uniquization of constants breaks constant alignment dje at gcc dot gnu.org
2013-07-22 21:40 ` [Bug middle-end/57955] " dje at gcc dot gnu.org
2013-07-22 22:22 ` ebotcazou at gcc dot gnu.org
2013-07-22 23:39 ` dje at gcc dot gnu.org
2013-07-23 21:37 ` ebotcazou at gcc dot gnu.org
2013-07-23 23:40 ` [Bug middle-end/57955] [4.6/4.7/4.8/4.9 Regression] Uniquization of constants reduces alignment of initializers dje at gcc dot gnu.org
2013-08-28  9:19 ` [Bug middle-end/57955] [4.7/4.8/4.9 " rguenth at gcc dot gnu.org
2013-10-30 13:17 ` rguenth at gcc dot gnu.org
2014-06-12 13:42 ` [Bug middle-end/57955] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
2014-12-19 13:25 ` [Bug middle-end/57955] [4.8/4.9/5 " jakub at gcc dot gnu.org
2015-02-19  9:25 ` jakub at gcc dot gnu.org
2015-02-19 14:26 ` jakub at gcc dot gnu.org [this message]
2015-06-23  8:17 ` [Bug middle-end/57955] [4.8/4.9/5/6 " rguenth at gcc dot gnu.org
2015-06-26 19:53 ` [Bug middle-end/57955] [4.9/5/6 " jakub at gcc dot gnu.org
2015-06-26 20:26 ` jakub at gcc dot gnu.org
2021-05-14  9:46 ` [Bug middle-end/57955] [9/10/11/12 " jakub at gcc dot gnu.org
2021-06-01  8:06 ` rguenth at gcc dot gnu.org
2021-12-22 15:39 ` pinskia at gcc dot gnu.org
2021-12-23 10:27 ` ebotcazou at gcc dot gnu.org
2021-12-23 13:55 ` dje at gcc dot gnu.org
2022-05-27  9:34 ` [Bug middle-end/57955] [10/11/12/13 " rguenth at gcc dot gnu.org
2022-06-28 10:30 ` jakub at gcc dot gnu.org
2023-07-07 10:29 ` [Bug middle-end/57955] [11/12/13/14 " rguenth at gcc dot gnu.org

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=bug-57955-4-3eRoMAO24s@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).