public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: gcc-patches@gcc.gnu.org
Subject: [PATCH] i386: Fix up __bf16 handling on ia32
Date: Wed, 19 Oct 2022 10:50:00 +0200	[thread overview]
Message-ID: <Y0+6OPW020p5Zran@tucnak> (raw)

Hi!

Last night's testing of the libstdc++ changes revealed a problem
in the __bf16 backend registration (while _Float16 seems ok).
The problem is that for both BFmode and HFmode we require TARGET_SSE2,
the generic code creates {,b}float16_type_node only if that is true
at the start of the TU and the builtins for the type are only
created in that case (many __builtin_*f16 for HFmode and __builtin_nansf16b
for BFmode).  Now, for _Float16 I've kept what the code did previously,
if float16_type_node from generic code is NULL, create ix86_float16_type_node
and register _Float16 for it, but for __bf16 I've changed it so that
if bfloat16_type_node from generic code is NULL,
ix86_register_bf16_builtin_type makes bfloat16_type_node non-NULL.
This has an unfortunate consequence though, __STDCPP_BFLOAT16_T__ is
predefined for C++23, __BFLT16_*__ macros are predefined as well, but
the type doesn't really work (errors whenever it is used) and the builtin
isn't defined.

The following patch fixes that by going with what we do for HFmode,
bfloat16_type_node stays as initialized by generic code and we have a local
type for backend use.  On the other side, nothing used ix86_bf16_ptr_type_node
so that is now dropped.

Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-10-19  Jakub Jelinek  <jakub@redhat.com>

	* config/i386/i386-builtins.cc (ix86_bf16_ptr_type_node): Remove.
	(ix86_bf16_type_node): New variable.
	(ix86_register_bf16_builtin_type): If bfloat16_type_node is NULL
	from generic code, set only ix86_bf16_type_node to a new REAL_TYPE
	rather than bfloat16_type_node, otherwise set ix86_bf16_type_node
	to bfloat16_type_node.  Register __bf16 on ix86_bf16_type_node
	rather than bfloat16_type_node.  Don't initialize unused
	ix86_bf16_ptr_type_node.
	* config/i386/i386-builtin-types.def (BFLOAT16): Use
	ix86_bf16_type_node rather than bfloat16_type_node.

--- gcc/config/i386/i386-builtins.cc.jj	2022-10-14 22:32:30.088698145 +0200
+++ gcc/config/i386/i386-builtins.cc	2022-10-19 01:11:33.685164338 +0200
@@ -126,7 +126,7 @@ BDESC_VERIFYS (IX86_BUILTIN_MAX,
 static GTY(()) tree ix86_builtin_type_tab[(int) IX86_BT_LAST_CPTR + 1];
 
 tree ix86_float16_type_node = NULL_TREE;
-tree ix86_bf16_ptr_type_node = NULL_TREE;
+tree ix86_bf16_type_node = NULL_TREE;
 
 /* Retrieve an element from the above table, building some of
    the types lazily.  */
@@ -1373,17 +1373,16 @@ ix86_register_bf16_builtin_type (void)
 {
   if (bfloat16_type_node == NULL_TREE)
     {
-      bfloat16_type_node = make_node (REAL_TYPE);
-      TYPE_PRECISION (bfloat16_type_node) = 16;
-      SET_TYPE_MODE (bfloat16_type_node, BFmode);
-      layout_type (bfloat16_type_node);
+      ix86_bf16_type_node = make_node (REAL_TYPE);
+      TYPE_PRECISION (ix86_bf16_type_node) = 16;
+      SET_TYPE_MODE (ix86_bf16_type_node, BFmode);
+      layout_type (ix86_bf16_type_node);
     }
+  else
+    ix86_bf16_type_node = bfloat16_type_node;
 
   if (!maybe_get_identifier ("__bf16") && TARGET_SSE2)
-    {
-      lang_hooks.types.register_builtin_type (bfloat16_type_node, "__bf16");
-      ix86_bf16_ptr_type_node = build_pointer_type (bfloat16_type_node);
-    }
+    lang_hooks.types.register_builtin_type (ix86_bf16_type_node, "__bf16");
 }
 
 static void
--- gcc/config/i386/i386-builtin-types.def.jj	2022-10-14 22:32:30.088698145 +0200
+++ gcc/config/i386/i386-builtin-types.def	2022-10-19 01:11:58.030845416 +0200
@@ -69,7 +69,7 @@ DEF_PRIMITIVE_TYPE (UINT16, short_unsign
 DEF_PRIMITIVE_TYPE (INT64, long_long_integer_type_node)
 DEF_PRIMITIVE_TYPE (UINT64, long_long_unsigned_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT16, ix86_float16_type_node)
-DEF_PRIMITIVE_TYPE (BFLOAT16, bfloat16_type_node)
+DEF_PRIMITIVE_TYPE (BFLOAT16, ix86_bf16_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT, float_type_node)
 DEF_PRIMITIVE_TYPE (DOUBLE, double_type_node)
 DEF_PRIMITIVE_TYPE (FLOAT80, float80_type_node)


	Jakub


             reply	other threads:[~2022-10-19  8:50 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19  8:50 Jakub Jelinek [this message]
2022-10-19  9:06 ` Uros Bizjak

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=Y0+6OPW020p5Zran@tucnak \
    --to=jakub@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=ubizjak@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).