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.
next prev 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: linkBe 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).