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

On Wed, Oct 19, 2022 at 10:50 AM Jakub Jelinek <jakub@redhat.com> wrote:
>
> 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.

LGTM.

Thanks,
Uros.

> --- 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  9:06 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-19  8:50 Jakub Jelinek
2022-10-19  9:06 ` Uros Bizjak [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=CAFULd4YfXdgvZNhxod3ZH6EHPbzsMbzJXAEGiaA6hXJLWmqTVw@mail.gmail.com \
    --to=ubizjak@gmail.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).