From: Kyrill Tkachov <kyrylo.tkachov@arm.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: Eric Botcazou <ebotcazou@adacore.com>
Subject: Re: [PATCH][simplify-rtx] PR 65235: Calculate element size correctly when simplifying (vec_select (vec_concat (const_int) (...)) [...])
Date: Wed, 04 Mar 2015 11:05:00 -0000 [thread overview]
Message-ID: <54F6E702.5070709@arm.com> (raw)
In-Reply-To: <alpine.DEB.2.11.1503041134330.2126@stedding.saclay.inria.fr>
On 04/03/15 10:41, Marc Glisse wrote:
> On Wed, 4 Mar 2015, Kyrill Tkachov wrote:
>
>> Hi all,
>>
>> This patch fixes PR rtl-optimization 65235.
>> As mentioned in bugzilla:
>> Combine tries to combine:
>> (insn 72 71 73 2 (set (reg:V2DI 117 [ D.18177 ])
>> (vec_concat:V2DI (reg:DI 176 [ D.18179 ])
>> (reg:DI 114 [ D.18168 ])))
>> (expr_list:REG_DEAD (reg:DI 176 [ D.18179 ])
>> (expr_list:REG_DEAD (reg:DI 114 [ D.18168 ])
>>
>> and
>>
>> (insn 104 102 105 2 (set (reg:DI 193 [ D.18168 ])
>> (vec_select:DI (reg:V2DI 117 [ D.18177 ])
>> (parallel [
>> (const_int 0 [0])
>> ])))
>> (expr_list:REG_DEAD (reg:V2DI 117 [ D.18177 ])
>> (nil)))
>>
>> but ends up generating:
>> (set (reg:DI 193 [ D.18168 ])
>> (reg:DI 114 [ D.18168 ]))
>>
>>
>> that is, it gets the wrong element of the vec_concat.
>>
>> The problem is that in simplify-rtx it tries to get the size of the
>> first element, compare the requested offset against it and pick the
>> second element if the offset is greater than that size. If the first
>> element is a const_int, the size is 0, so it will always pick the second
>> part.
> I am a bit surprised that the first element is a const_int and not reg
> 176, maybe that's why it doesn't reproduce on other platforms? Not that it
> really matters.
Yeah, I guess combine tries various whacky combinations when it's trying to
munge things together.
>
>> The patch fixes that by calculating the size of the first element by
>> taking the size of the outer mode and subtracting the size of the second
>> element.
> I wonder if we should admit that vector sizes are always a power of 2 and
> use half the size of the outer mode?
Perhaps. I tried to be as defensive as possible since I'm not sure what
the restrictions
are on vec_select+vec_concat combinations.
Kyrill
>
>> I've added an assert to make sure that the second element is not also a
>> const_int, as a vec_concat of const_ints doesn't make sense as far as I
>> can see.
next prev parent reply other threads:[~2015-03-04 11:05 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-04 9:37 Kyrill Tkachov
2015-03-04 10:41 ` Marc Glisse
2015-03-04 11:05 ` Kyrill Tkachov [this message]
2015-03-06 9:42 ` Eric Botcazou
2015-03-12 13:28 ` Kyrill Tkachov
2015-03-12 13:33 ` 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=54F6E702.5070709@arm.com \
--to=kyrylo.tkachov@arm.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@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: 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).