public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rsandifo at gcc dot gnu dot org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/27770] [4.2 Regression] wrong code in spec tests for -ftree-vectorize -maltivec Date: Tue, 06 Jun 2006 09:02:00 -0000 [thread overview] Message-ID: <20060606085423.31352.qmail@sourceware.org> (raw) In-Reply-To: <bug-27770-4503@http.gcc.gnu.org/bugzilla/> ------- Comment #7 from rsandifo at gcc dot gnu dot org 2006-06-06 08:54 ------- Based on David's descripion, a reduced testcase appears to be: static short f[100]; int bar (void) { return f[0]; } void foo (void) { int i; for (i = 0; i < 100; i++) f[i]++; } Looking at the assembly output of "-O2 -ftree-vectorize -maltivec -mabi=altivec", it seems that "f" will only be guaranteed 2-byte alignment with -fsection-anchors. Without -fno-section-anchors, "f" gets the expected 16-byte alignment. This is an ordering problem. gcc is compiling bar() first, and generating code on the assumption that "f" has natural alignment. The vectoriser then increases the alignment of "f", which throws off any layout based on the original natural alignment. If bar() is compiled first, then gcc really does need to be able to place "f" at a fixed offset in its section, so that it can use section anchors to access "f". So I think the possible fixes are: (1) Don't use section anchors for "f" in bar() (2) Don't increase the alignment of "f" in foo() (3) Increase the alignment of "f" before compiling either foo() or bar() (1) implies either (1a) not using section anchors for vectorisable variables or (1b) disabling -fsection-anchors when -ftree-vectorize is in effect. (2) implies either (2a) not increasing the alignment of variables that have already been assigned a block offset or (2b) preventing -ftree-vectorize from increasing alignment when -fsection-anchors is in effect. (3) implies increasing the alignment of all vectorisable variables if both -fsection-anchors and -ftree-vectorize are in effect. Neither (2a) nor (2b) is acceptable IMO. (I don't think (2a) is acceptable because the order of compilation is not guaranteed.) (1) is a worst-case fall-back position, with (1a) obviously being better than (1b). (3) seems more appealing, but only if we accept that -fsection-anchors -ftree-vectorize may increase the alignment of variables that do not in fact get vectorised. This is going to be a data size hit. (Hopefully it will only be a small hit, and I suppose -ftree-vectorize is already a "speed over size" optimisation.) If we choose (1) or (3), I suppose we should also add a gcc_assert() that the vectoriser is not increasing the alignment of a variable that has already been placed in a block (i.e. assert that (2a) would then be a no-op). Richard -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27770
next prev parent reply other threads:[~2006-06-06 8:54 UTC|newest] Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top 2006-05-25 16:23 [Bug target/27770] New: " janis at gcc dot gnu dot org 2006-05-25 16:31 ` [Bug target/27770] " janis at gcc dot gnu dot org 2006-05-25 16:45 ` pinskia at gcc dot gnu dot org 2006-05-25 17:28 ` dje at gcc dot gnu dot org 2006-05-29 23:18 ` [Bug target/27770] [4.2 Regression] " pinskia at gcc dot gnu dot org 2006-06-04 19:31 ` mmitchel at gcc dot gnu dot org 2006-06-05 10:34 ` steven at gcc dot gnu dot org 2006-06-05 21:01 ` janis at gcc dot gnu dot org 2006-06-05 21:26 ` dje at gcc dot gnu dot org 2006-06-06 9:02 ` rsandifo at gcc dot gnu dot org [this message] 2006-06-06 14:34 ` pinskia at gcc dot gnu dot org 2006-06-06 15:10 ` richard at codesourcery dot com 2006-06-06 15:16 ` dje at gcc dot gnu dot org 2006-06-06 15:18 ` richard at codesourcery dot com 2006-06-06 15:23 ` pinskia at gcc dot gnu dot org 2006-06-06 15:43 ` dje at gcc dot gnu dot org 2006-06-06 16:06 ` richard at codesourcery dot com 2006-06-06 16:37 ` rguenth at gcc dot gnu dot org 2006-06-07 21:52 ` dje at gcc dot gnu dot org 2006-07-02 13:14 ` [Bug middle-end/27770] " hubicka at gcc dot gnu dot org 2006-07-02 13:39 ` richard at codesourcery dot com 2006-07-23 19:04 ` dorit at il dot ibm dot com 2006-07-29 20:30 ` patchapp at dberlin dot org 2006-08-03 20:35 ` dorit at gcc dot gnu dot org 2006-08-04 6:05 ` bonzini at gnu dot org 2006-08-04 16:48 ` janis at gcc dot gnu dot org 2006-08-04 17:03 ` pinskia at gcc dot gnu dot org 2006-08-07 7:09 ` dorit at il dot ibm dot com 2006-08-22 16:06 ` howarth at nitro dot med dot uc dot edu 2006-08-22 16:08 ` pinskia at gcc dot gnu dot 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=20060606085423.31352.qmail@sourceware.org \ --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).