From: Jeff Law <law@redhat.com>
To: Eric Botcazou <ebotcazou@adacore.com>, gcc-patches@gcc.gnu.org
Cc: Richard Sandiford <rdsandiford@googlemail.com>,
Richard Sandiford <richard.sandiford@arm.com>,
Alan Hayward <Alan.Hayward@arm.com>,
"steven@gcc.gnu.org" <steven@gcc.gnu.org>
Subject: Re: [PATCH][rtlanal.c][BE][1/2] Fix vector load/stores to not use ld1/st1
Date: Wed, 14 Jan 2015 08:37:00 -0000 [thread overview]
Message-ID: <54B61C4F.9070103@redhat.com> (raw)
In-Reply-To: <13670880.MKCSlOSr3D@polaris>
On 01/13/15 11:55, Eric Botcazou wrote:
>
>> (1) we have a non-paradoxical subreg;
>> (2) both (reg:ymode xregno) and (reg:xmode xregno) occupy full
>> hard registers (no padding or unused upper bits);
>> (3) (reg:ymode xregno) and (reg:xmode xregno) store the same number
>> of bytes (X) in each constituent hard register;
>> (4) the offset is a multiple of X, i.e. the data we're accessing
>> is aligned to a register boundary; and
>> (5) endianness is regular (no differences between words and bytes,
>> or between registers and memory)
>
> OK, that's a nice translation of the new code. :-)
>
> It seems to me that the patch wants to extend the support of generic subregs
> to modes whose sizes are not multiple of each other, which is a requirement of
> the existing code, but does that in a very specific case for the sake of the
> ARM port without saying where all the above restrictions come from.
Basically we're lifting the restriction that the the sizes are multiples
of each other. The requirements above are the set where we know it will
work. They are target independent, but happen to match what the ARM needs.
The certainly do short circuit the meat of the function, that's the
whole point, there's this set of conditions under which we know this
will work and when they hold, we bypass.
Now one could argue that instead of bypassing we should put the code to
handle this situation further down. I'd be leery of doing that just
from a complexity standpoint. But one could also argue that short
circuiting like the patch does adds complexity as well and may be a bit
kludgy.
Maybe the way forward here is for someone to try and integrate this
support in the main part of the code and see how it looks. Then we can
pick one.
The downside is since this probably isn't a regression that work would
need to happen quickly to make it into gcc-5.
Which leads to another option, get the release managers to sign off on
the kludge after gcc-5 branches and only install the kludge on the gcc-5
branch and insisting the other solution go in for gcc-6 and beyond. Not
sure if they'd do that, but it's a discussion that could happen.
jeff
next prev parent reply other threads:[~2015-01-14 7:35 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-12 11:08 Alan Hayward
2014-12-12 16:21 ` Richard Sandiford
2014-12-13 11:34 ` Eric Botcazou
2014-12-15 9:21 ` Richard Sandiford
2014-12-15 20:52 ` Eric Botcazou
2014-12-15 21:56 ` Richard Sandiford
2014-12-19 22:53 ` Eric Botcazou
2015-01-10 14:59 ` Richard Sandiford
2015-01-13 19:04 ` Eric Botcazou
2015-01-14 8:37 ` Jeff Law [this message]
2015-01-14 9:55 ` Marcus Shawcroft
2015-01-20 21:45 ` Richard Sandiford
2015-01-21 1:48 ` Eric Botcazou
2015-01-21 18:03 ` Richard Sandiford
2015-01-14 7:48 ` Jeff Law
2015-01-09 7:12 ` Jeff Law
-- strict thread matches above, loose matches on Subject: below --
2014-12-10 9:51 Alan Hayward
2014-12-10 10:25 ` Marcus Shawcroft
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=54B61C4F.9070103@redhat.com \
--to=law@redhat.com \
--cc=Alan.Hayward@arm.com \
--cc=ebotcazou@adacore.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=rdsandiford@googlemail.com \
--cc=richard.sandiford@arm.com \
--cc=steven@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).