public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Sandiford <richard.sandiford@arm.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] optabs: Don't use scalar conversions for vectors [PR93843]
Date: Thu, 27 Feb 2020 10:00:00 -0000	[thread overview]
Message-ID: <mpt36awuz7q.fsf@arm.com> (raw)
In-Reply-To: <20200226125743.GV2155@tucnak> (Jakub Jelinek's message of "Wed,	26 Feb 2020 13:57:43 +0100")

Jakub Jelinek <jakub@redhat.com> writes:
> On Wed, Feb 26, 2020 at 11:43:10AM +0000, Richard Sandiford wrote:
>> In this PR we had a conversion between two integer vectors that
>> both had scalar integer modes.  We then tried to implement the
>> conversion using the scalar optab for those modes, instead of
>> doing the conversion elementwise.
>> 
>> I wondered about letting through scalar modes for single-element
>> vectors, but I don't have any evidence that that's useful/necessary,
>> so it seemed better to keep things simple.
>> 
>> Tested on aarch64-linux-gnu, armeb-eabi and x86_64-linux-gnu.
>
> Won't this prevent even say __v4qi to __v4uqi and similar conversions
> with scalar modes for those where we don't need any kind of extensions,
> just reinterpret the bits?

Those kinds of conversions aren't accepted by the function anyway,
even for vector modes, since there's no associated optab that they
could use.  The vectoriser handles them using VCEs instead, via
vectorizable_assignment rather than vectorizable_conversion.

I guess for GCC 11 we could allow NOP_EXPR to be used for reinterpreting
signedness if that seems like the right thing to do.

Thanks,
Richard

      reply	other threads:[~2020-02-27 10:00 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-26 11:43 Richard Sandiford
2020-02-26 12:22 ` Richard Biener
2020-02-26 12:57 ` Jakub Jelinek
2020-02-27 10:00   ` Richard Sandiford [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=mpt36awuz7q.fsf@arm.com \
    --to=richard.sandiford@arm.com \
    --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).