public inbox for jit@gcc.gnu.org
 help / color / mirror / Atom feed
From: Antoni Boucher <bouanto@zoho.com>
To: Tom Tromey <tom@tromey.com>
Cc: Antoni Boucher via Gcc-patches <gcc-patches@gcc.gnu.org>,
	jit@gcc.gnu.org
Subject: Re: [PATCH] libgccjit: Handle truncation and extension for casts [PR 95498]
Date: Sat, 20 Feb 2021 17:17:06 -0500	[thread overview]
Message-ID: <20210220221706.ewfq2b3i2mzx4ice@bouanto-desktop.localdomain> (raw)
In-Reply-To: <874ki6txcc.fsf@tromey.com>

Hi.
Thanks for your feedback!

See answers below:

On Sat, Feb 20, 2021 at 11:20:35AM -0700, Tom Tromey wrote:
>>>>>> "Antoni" == Antoni Boucher via Gcc-patches <gcc-patches@gcc.gnu.org> writes:
>
>Antoni> gcc/jit/
>Antoni> 	PR target/95498
>Antoni> 	* jit-playback.c: Add support to handle truncation and extension
>Antoni> 	in the convert function.
>
>Antoni> +  switch (dst_code)
>Antoni> +    {
>Antoni> +    case INTEGER_TYPE:
>Antoni> +    case ENUMERAL_TYPE:
>Antoni> +      t_ret = convert_to_integer (dst_type, expr);
>Antoni> +      goto maybe_fold;
>Antoni> +
>Antoni> +    default:
>Antoni> +      gcc_assert (gcc::jit::active_playback_ctxt);
>Antoni> +      gcc::jit::active_playback_ctxt->add_error (NULL, "unhandled conversion");
>Antoni> +      fprintf (stderr, "input expression:\n");
>Antoni> +      debug_tree (expr);
>Antoni> +      fprintf (stderr, "requested type:\n");
>Antoni> +      debug_tree (dst_type);
>Antoni> +      return error_mark_node;
>Antoni> +
>Antoni> +    maybe_fold:
>Antoni> +      if (TREE_CODE (t_ret) != C_MAYBE_CONST_EXPR)
>Antoni> +	t_ret = fold (t_ret);
>Antoni> +      return t_ret;
>
>It seems weird to have a single 'goto' to maybe_fold, especially inside
>a switch like this.
>
>If you think the maybe_fold code won't be reused, then it should just be
>hoisted up and the 'goto' removed.

This actually depends on how the support for cast between integers and 
pointers will be implemented (see below).
If we will support truncating pointers (does that even make sense? and I 
guess we cannot extend a pointer unless we add the support for 
uint128_t), that label will be reused for that case.
Otherwise, it might not be reused.

So, please tell me which option to choose and I'll update my patch.

>On the other hand, if the maybe_fold code might be reused for some other
>case, then I suppose I would have the case end with 'break' and then
>have this code outside the switch.
>
>
>In another message, you wrote:
>
>Antoni> For your question, the current code already works with boolean and
>Antoni> reals and casts between integers and pointers is currently not
>Antoni> supported.
>
>I am curious why this wasn't supported.  It seems like something that
>one might want to do.

I have no idea as this is my first contribution to gcc.
But this would be indeed very useful and I opened an issue about this: 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95438

>thanks,
>Tom

Thanks!

  reply	other threads:[~2021-02-20 22:17 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-13  0:30 Antoni Boucher
2020-07-14 21:15 ` David Malcolm
2020-07-21 21:29 ` Andrea Corallo
2020-10-15 19:00   ` Antoni Boucher
2021-02-13  1:35   ` Antoni Boucher
2021-02-20 18:20 ` Tom Tromey
2021-02-20 22:17   ` Antoni Boucher [this message]
2021-05-13  8:34     ` Martin Liška
2021-05-13 22:13     ` David Malcolm
2021-05-13 23:31       ` Antoni Boucher
2021-05-13 23:58         ` David Malcolm
2021-05-26  0:16           ` Antoni Boucher
2021-05-27 22:21             ` David Malcolm
2021-05-28  1:22               ` Antoni Boucher
2021-06-11 17:49                 ` David Malcolm
2021-06-18 20:42                   ` Antoni Boucher
2021-06-18 20:54                     ` David Malcolm
2021-06-18 21:11                       ` Antoni Boucher
2021-06-19  9:08                         ` Bernhard Reutner-Fischer
2021-07-06 13:00                           ` Antoni Boucher
2021-07-08 20:44                             ` David Malcolm
2021-07-08 21:28                               ` Antoni Boucher
2021-07-08 21:34                                 ` 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=20210220221706.ewfq2b3i2mzx4ice@bouanto-desktop.localdomain \
    --to=bouanto@zoho.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jit@gcc.gnu.org \
    --cc=tom@tromey.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).