From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] Small hack for DECL_MODE lack of vector_type_mode-like behavior (PR target/78643, PR target/80583)
Date: Sat, 02 Dec 2017 07:53:00 -0000 [thread overview]
Message-ID: <34566DF3-6E93-42BE-9BA8-60384AF501CC@suse.de> (raw)
In-Reply-To: <20171202001415.GF2353@tucnak>
On December 2, 2017 1:14:15 AM GMT+01:00, Jakub Jelinek <jakub@redhat.com> wrote:
>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?
OK.
Richard.
>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
prev parent reply other threads:[~2017-12-02 7:53 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-02 0:14 Jakub Jelinek
2017-12-02 7:53 ` Richard Biener [this message]
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=34566DF3-6E93-42BE-9BA8-60384AF501CC@suse.de \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
/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).