public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

             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).