public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Robin Dapp <rdapp.gcc@gmail.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, Tamar.Christina@arm.com
Subject: Re: [PATCH] match.pd: Use element_mode instead of TYPE_MODE.
Date: Tue, 27 Jun 2023 09:50:38 +0000 (UTC)	[thread overview]
Message-ID: <nycvar.YFH.7.77.849.2306270946490.4723@jbgna.fhfr.qr> (raw)
In-Reply-To: <e160cee4-fd96-2a63-c48b-d91c4fecbc49@gmail.com>

On Tue, 27 Jun 2023, Robin Dapp wrote:

> > Yeah, the optab should already have the fallback of WIDENing here?
> > So why does that fail?
> 
> We reach
>  if (CLASS_HAS_WIDER_MODES_P (mclass))
> which returns false because mclass == MODE_VECTOR_FLOAT.
> CLASS_HAS_WIDER_MODES_P only handles non-vector classes?
> Same for FOR_EACH_WIDER_MODE that follows.

Oh, so this is about vector modes.  So yes, for vectors we need to
perform this test.  In other places we do

        && (!VECTOR_MODE_P (TYPE_MODE (type))
            || (VECTOR_MODE_P (TYPE_MODE (itype))
                && optab_handler (and_optab,
                                  TYPE_MODE (itype)) != 
CODE_FOR_nothing)))

so I suggest to do a similar VECTOR_MODE_P check and your original test.
So

      && (!VECTOR_MODE_P (TYPE_MODE (newtype))
          || target_supports_op_p (newtype, op, optab_default))

OK with that change.

Thanks,
Richard.

  reply	other threads:[~2023-06-27  9:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-26 14:26 Robin Dapp
2023-06-26 23:18 ` Jeff Law
2023-06-27  6:30 ` Richard Biener
2023-06-27  6:47   ` Robin Dapp
2023-06-27  7:03     ` Richard Biener
2023-06-27  7:42       ` Robin Dapp
2023-06-27  8:46         ` Richard Biener
2023-06-27  9:42           ` Robin Dapp
2023-06-27  9:50             ` Richard Biener [this message]
2023-06-27  9:55               ` Robin Dapp
2023-06-27 10:05                 ` Richard Biener
2023-06-27 15:55                   ` Robin Dapp
2023-06-27 23:05                     ` Andrew Pinski
2023-06-28  7:27                       ` Andrew Pinski

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=nycvar.YFH.7.77.849.2306270946490.4723@jbgna.fhfr.qr \
    --to=rguenther@suse.de \
    --cc=Tamar.Christina@arm.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=rdapp.gcc@gmail.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).