public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Eric Botcazou <ebotcazou@adacore.com>
Cc: "gcc-patches\@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	 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: Mon, 15 Dec 2014 09:21:00 -0000	[thread overview]
Message-ID: <87fvch8eo0.fsf@e105548-lin.cambridge.arm.com> (raw)
In-Reply-To: <7355255.n9uUnY8azR@polaris> (Eric Botcazou's message of "Sat, 13	Dec 2014 11:25:16 +0000")

Eric Botcazou <ebotcazou@adacore.com> writes:
>> FWIW I agree this is the right approach, although I can't approve it.
>> The assert above is guarding code that deals with a very general case,
>> including some unusual combinations, so I don't think it would be a
>> good idea to try to remove it entirely.
>
> Yes, but the patch is a bit of kludge since it short-circuits the meat of the 
> function:
>
>    /* This should always pass, otherwise we don't know how to verify
>      the constraint.  These conditions may be relaxed but
>      subreg_regno_offset would need to be redesigned.  */
>   gcc_assert ((GET_MODE_SIZE (xmode) % GET_MODE_SIZE (ymode)) == 0);
>   gcc_assert ((nregs_xmode % nregs_ymode) == 0);
>
> So what would it take to do things properly here, i.e. relax the conditions 
> and adjust downstream?

What do you think we should relax it to though?  Obviously there's a balance
here between relaxing things enough and not relaxing them too far (so that
the EImode AArch64 thing I mentioned is still a noisy failure, for example).
ISTM the patch deals with the only significant case that is obviously safe
for modes that are not a power of 2 in size.

If you're saying that the condition itself is OK, but that the code should
be further down in the function, then I don't think that would gain much.
We already have early-outs for the simple cases, such as:

  /* Paradoxical subregs are otherwise valid.  */
  if (!rknown
      && offset == 0
      && GET_MODE_PRECISION (ymode) > GET_MODE_PRECISION (xmode))
    {
      info->representable_p = true;
      /* If this is a big endian paradoxical subreg, which uses more
	 actual hard registers than the original register, we must
	 return a negative offset so that we find the proper highpart
	 of the register.  */
      if (GET_MODE_SIZE (ymode) > UNITS_PER_WORD
	  ? REG_WORDS_BIG_ENDIAN : BYTES_BIG_ENDIAN)
	info->offset = nregs_xmode - nregs_ymode;
      else
	info->offset = 0;
      info->nregs = nregs_ymode;
      return;
    }
  [...]
  /* Lowpart subregs are otherwise valid.  */
  if (!rknown && offset == subreg_lowpart_offset (ymode, xmode))
    {
      info->representable_p = true;
      rknown = true;

      if (offset == 0 || nregs_xmode == nregs_ymode)
	{
	  info->offset = 0;
	  info->nregs = nregs_ymode;
	  return;
	}
    }

which also come before the assert.

Thanks,
Richard

  reply	other threads:[~2014-12-15  9:07 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 [this message]
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
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=87fvch8eo0.fsf@e105548-lin.cambridge.arm.com \
    --to=richard.sandiford@arm.com \
    --cc=Alan.Hayward@arm.com \
    --cc=ebotcazou@adacore.com \
    --cc=gcc-patches@gcc.gnu.org \
    --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).