From: Segher Boessenkool <segher@kernel.crashing.org>
To: Walter Lee <walt@mellanox.com>
Cc: gcc-patches@gcc.gnu.org, guybe@mellanox.com
Subject: Re: [PATCH] Fix improper combiner optimization of mixed mode vector/scalar expressions (PR 79365)
Date: Fri, 03 Feb 2017 23:22:00 -0000 [thread overview]
Message-ID: <20170203232246.GY21840@gate.crashing.org> (raw)
In-Reply-To: <265085ca-a7c3-7c65-eca8-8a2df49b8b8c@mellanox.com>
Hi,
A couple of things. Firstly, we are in stage 4 now, so unless this
is a regression it will have to wait for GCC 8. I can carry the patch
or you can repost it when we are in stage 1.
Secondly, you forgot the changelog.
On Fri, Feb 03, 2017 at 03:03:06PM -0500, Walter Lee wrote:
> In looking at PR 79365 I found that the problem is actually in the
> combiner. The combiner sometimes applies scalar optimizations to
> vector context where they are invalid. i.e. (a > b) >> 1 can optimize
> to 0 if ">" is a scalar op but not if it is a vector op. The reason
> this shows up on tile* and not other architectures is because tile*
> uses the same register file for both scalars and vectors, so the
> combiner sees these mixed mode expressions on tile* that would go
> through memory on other architectures.
There are other architectures that are similar, but perhaps none that
have their vector size equal to their most common integer size.
> I have found two places where this improper optimization occurs.
> --- a/gcc/combine.c
> +++ b/gcc/combine.c
> @@ -7267,6 +7267,7 @@ expand_field_assignment (const_rtx x)
> else if (GET_CODE (SET_DEST (x)) == SUBREG
> /* We need SUBREGs to compute nonzero_bits properly. */
> && nonzero_sign_valid
> + && !VECTOR_MODE_P (GET_MODE (SET_DEST (x)))
> && (((GET_MODE_SIZE (GET_MODE (SET_DEST (x)))
> + (UNITS_PER_WORD - 1)) / UNITS_PER_WORD)
> == ((GET_MODE_SIZE (GET_MODE (SUBREG_REG (SET_DEST (x))))
Please use SCALAR_INT_MODE_P instead.
> @@ -13030,6 +13031,7 @@ record_dead_and_set_regs_1 (rtx dest, const_rtx
> setter, void *data)
> record_value_for_reg (dest, record_dead_insn, SET_SRC (setter));
> else if (GET_CODE (setter) == SET
> && GET_CODE (SET_DEST (setter)) == SUBREG
> + && !VECTOR_MODE_P (GET_MODE (SET_DEST (setter)))
> && SUBREG_REG (SET_DEST (setter)) == dest
> && GET_MODE_PRECISION (GET_MODE (dest)) <= BITS_PER_WORD
> && subreg_lowpart_p (SET_DEST (setter)))
What is this for? It isn't triggered by the testcase in the PR.
You should add testcases to the testsuite, too. In gcc.target is fine
if they are tile*-specific.
Thanks,
Segher
next prev parent reply other threads:[~2017-02-03 23:22 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-03 20:03 Walter Lee
2017-02-03 20:16 ` Walter Lee
2017-02-03 23:22 ` Segher Boessenkool [this message]
2017-02-04 17:51 ` Walter Lee
2017-04-28 22:09 ` Jeff Law
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=20170203232246.GY21840@gate.crashing.org \
--to=segher@kernel.crashing.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=guybe@mellanox.com \
--cc=walt@mellanox.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).