public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: David Malcolm <dmalcolm@redhat.com>
To: Kewen Lin <linkw@linux.ibm.com>,
	gcc-patches@gcc.gnu.org, jit@gcc.gnu.org
Subject: Re: [PATCH 10/52] jit: Replace uses of {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
Date: Thu, 13 Jun 2024 09:44:55 -0400	[thread overview]
Message-ID: <24355f0ad35a6ce7619be47c0f6cd69624d250cf.camel@redhat.com> (raw)
In-Reply-To: <7c9b2ed53cee1c8c7d5b47abbf963acc2bf5a62e.1717134752.git.linkw@linux.ibm.com>

On Sun, 2024-06-02 at 22:01 -0500, Kewen Lin wrote:
> Joseph pointed out "floating types should have their mode,
> not a poorly defined precision value" in the discussion[1],
> as he and Richi suggested, the existing macros
> {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE will be replaced with a
> hook mode_for_floating_type.  Unlike the other FEs, for the
> uses in recording::memento_of_get_type::get_size, since
> {float,{,long_}double}_type_node haven't been initialized
> yet, this is to replace {FLOAT,{,LONG_}DOUBLE}_TYPE_SIZE
> with calling hook targetm.c.mode_for_floating_type.
> 
> [1] https://gcc.gnu.org/pipermail/gcc-patches/2024-May/651209.html
> 
> gcc/jit/ChangeLog:
> 
>         * jit-recording.cc
> (recording::memento_of_get_type::get_size): Update
>         macros {FLOAT,DOUBLE,LONG_DOUBLE}_TYPE_SIZE by calling
>         targetm.c.mode_for_floating_type with
>         TI_{FLOAT,DOUBLE,LONG_DOUBLE}_TYPE.
> ---
>  gcc/jit/jit-recording.cc | 12 ++++++++----
>  1 file changed, 8 insertions(+), 4 deletions(-)
> 
> diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
> index 68a2e860c1f..7719b898e57 100644
> --- a/gcc/jit/jit-recording.cc
> +++ b/gcc/jit/jit-recording.cc
> @@ -21,7 +21,7 @@ along with GCC; see the file COPYING3.  If not see
>  #include "config.h"
>  #include "system.h"
>  #include "coretypes.h"
> -#include "tm.h"
> +#include "target.h"
>  #include "pretty-print.h"
>  #include "toplev.h"
>  
> @@ -2353,6 +2353,7 @@ size_t
>  recording::memento_of_get_type::get_size ()
>  {
>    int size;
> +  machine_mode m;
>    switch (m_kind)
>      {
>      case GCC_JIT_TYPE_VOID:
> @@ -2399,13 +2400,16 @@ recording::memento_of_get_type::get_size ()
>        size = 128;
>        break;
>      case GCC_JIT_TYPE_FLOAT:
> -      size = FLOAT_TYPE_SIZE;
> +      m = targetm.c.mode_for_floating_type (TI_FLOAT_TYPE);
> +      size = GET_MODE_PRECISION (m).to_constant ();
>        break;
>      case GCC_JIT_TYPE_DOUBLE:
> -      size = DOUBLE_TYPE_SIZE;
> +      m = targetm.c.mode_for_floating_type (TI_DOUBLE_TYPE);
> +      size = GET_MODE_PRECISION (m).to_constant ();
>        break;
>      case GCC_JIT_TYPE_LONG_DOUBLE:
> -      size = LONG_DOUBLE_TYPE_SIZE;
> +      m = targetm.c.mode_for_floating_type (TI_LONG_DOUBLE_TYPE);
> +      size = GET_MODE_PRECISION (m).to_constant ();
>        break;
>      case GCC_JIT_TYPE_SIZE_T:
>        size = MAX_BITS_PER_WORD;

[CCing jit mailing list]

Thanks for the patch; sorry for the delay in responding.

Did your testing include jit?  Note that --enable-languages=all does
*not* include it (due to it needing --enable-host-shared).

The jit::recording code runs *very* early - before toplev::main.  For
example, a call to gcc_jit_type_get_size can trigger the above code
path before toplev::main has run.

target.h says each target should have a:

  struct gcc_target targetm = TARGET_INITIALIZER;

Has targetm.c.mode_for_floating_type been initialized enough by that
static initialization?  Could the mode_for_floating_type hook be
relying on some target-specific dynamic initialization that hasn't run
yet?  (e.g. taking account of command-line options?)

Dave


       reply	other threads:[~2024-06-13 13:45 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1717134752.git.linkw@linux.ibm.com>
     [not found] ` <7c9b2ed53cee1c8c7d5b47abbf963acc2bf5a62e.1717134752.git.linkw@linux.ibm.com>
2024-06-13 13:44   ` David Malcolm [this message]
2024-06-14  2:16     ` Kewen.Lin
2024-06-24  6:23       ` Kewen.Lin
2024-06-24 22:25       ` David Malcolm

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=24355f0ad35a6ce7619be47c0f6cd69624d250cf.camel@redhat.com \
    --to=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jit@gcc.gnu.org \
    --cc=linkw@linux.ibm.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).