public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Segher Boessenkool <segher@kernel.crashing.org>
To: "Kewen.Lin" <linkw@linux.ibm.com>,
	gcc@gcc.gnu.org, Richard Biener <richard.guenther@gmail.com>,
	Peter Bergner <bergner@linux.ibm.com>,
	Jeff Law <jlaw@ventanamicro.com>,
	Jakub Jelinek <jakub@redhat.com>,
	Michael Meissner <meissner@linux.ibm.com>,
	richard.sandiford@arm.com
Subject: Re: RFC: Make builtin types only valid for some target features
Date: Mon, 5 Dec 2022 10:44:02 -0600	[thread overview]
Message-ID: <20221205164402.GW25951@gate.crashing.org> (raw)
In-Reply-To: <mpt359u2tnf.fsf@arm.com>

On Mon, Dec 05, 2022 at 07:31:48AM +0000, Richard Sandiford wrote:
> FWIW, the aarch64 fp move patterns emit the error directly.  They then
> expand an integer-mode move, to provide some error recovery.  (The
> alternative would be to make the error fatal.)
> 
> (define_expand "mov<mode>"
>   [(set (match_operand:GPF_TF_F16_MOV 0 "nonimmediate_operand")
> 	(match_operand:GPF_TF_F16_MOV 1 "general_operand"))]
>   ""
>   {
>     if (!TARGET_FLOAT)
>       {
> 	aarch64_err_no_fpadvsimd (<MODE>mode);
> 	machine_mode intmode
> 	  = int_mode_for_size (GET_MODE_BITSIZE (<MODE>mode), 0).require ();
> 	emit_move_insn (gen_lowpart (intmode, operands[0]),
> 			gen_lowpart (intmode, operands[1]));
> 	DONE;
>       }
> 
> This isn't as user-friendly as catching the error directly in the FE,
> but I think in practice it's going to be very hard to trap all invalid
> uses of a type there.  Also, the user error in these situations is likely
> to be forgetting to enable the right architecture feature, rather than
> accidentally using the wrong type.  So an error about missing architecture
> features is probably good enough in most cases.

The obvious problwem with this is you have to write it separately for
each and every such pattern.  But of course the opaque modes only ever
have mov patterns, everything else goes via builtins, so if this is the
best we can easily do, so be it :-)

Thanks,


Segher

      parent reply	other threads:[~2022-12-05 16:45 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-12-02  8:47 Kewen.Lin
2022-12-05  7:31 ` Richard Sandiford
2022-12-05 10:10   ` Andrew Pinski
2022-12-06  1:41     ` Kewen.Lin
2022-12-05 10:22   ` Kewen.Lin
2022-12-05 16:44   ` Segher Boessenkool [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=20221205164402.GW25951@gate.crashing.org \
    --to=segher@kernel.crashing.org \
    --cc=bergner@linux.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=jlaw@ventanamicro.com \
    --cc=linkw@linux.ibm.com \
    --cc=meissner@linux.ibm.com \
    --cc=richard.guenther@gmail.com \
    --cc=richard.sandiford@arm.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).