From: Jakub Jelinek <jakub@redhat.com>
To: Richard Biener <rguenther@suse.de>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] Small hack for DECL_MODE lack of vector_type_mode-like behavior (PR target/78643, PR target/80583)
Date: Sat, 02 Dec 2017 00:14:00 -0000 [thread overview]
Message-ID: <20171202001415.GF2353@tucnak> (raw)
Hi!
In TYPE_MODE we have a hack for vector types where we dynamically
adjust it based on whether it is used from a function where the vector mode
is or isn't supported (depending on target attribute, function
multiversioning, etc.), but we don't have anything like that in DECL_MODE.
The following is just a small hack that should be backportable to adjust
similarly DECL_MODE when looking at fields - for static VAR_DECLs we already
have code to cope with that, furthermore we need to cope there with the
case where DECL_RTL is created in one context and used in another one.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2017-12-01 Jakub Jelinek <jakub@redhat.com>
PR target/78643
PR target/80583
* expr.c (get_inner_reference): If DECL_MODE of a non-bitfield
is BLKmode for vector field with vector raw mode, use TYPE_MODE
instead of DECL_MODE.
* gcc.target/i386/pr80583.c: New test.
--- gcc/expr.c.jj 2017-11-27 09:27:41.000000000 +0100
+++ gcc/expr.c 2017-12-01 11:36:19.011863308 +0100
@@ -7032,7 +7032,16 @@ get_inner_reference (tree exp, HOST_WIDE
size. */
mode = TYPE_MODE (DECL_BIT_FIELD_TYPE (field));
else if (!DECL_BIT_FIELD (field))
- mode = DECL_MODE (field);
+ {
+ mode = DECL_MODE (field);
+ /* For vector fields re-check the target flags, as DECL_MODE
+ could have been set with different target flags than
+ the current function has. */
+ if (mode == BLKmode
+ && VECTOR_TYPE_P (TREE_TYPE (field))
+ && VECTOR_MODE_P (TYPE_MODE_RAW (TREE_TYPE (field))))
+ mode = TYPE_MODE (TREE_TYPE (field));
+ }
else if (DECL_MODE (field) == BLKmode)
blkmode_bitfield = true;
--- gcc/testsuite/gcc.target/i386/pr80583.c.jj 2017-12-01 11:44:28.106603314 +0100
+++ gcc/testsuite/gcc.target/i386/pr80583.c 2017-12-01 11:44:12.000000000 +0100
@@ -0,0 +1,13 @@
+/* PR target/80583 */
+/* { dg-do compile } */
+/* { dg-options "-O0 -mno-avx" } */
+
+typedef int V __attribute__((__vector_size__(32)));
+struct S { V a; };
+
+V __attribute__((target ("avx")))
+foo (struct S *b)
+{
+ V x = b->a;
+ return x;
+}
Jakub
next reply other threads:[~2017-12-02 0:14 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-02 0:14 Jakub Jelinek [this message]
2017-12-02 7:53 ` Richard Biener
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=20171202001415.GF2353@tucnak \
--to=jakub@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rguenther@suse.de \
/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).