public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Richard Biener <rguenther@suse.de>
To: Jakub Jelinek <jakub@redhat.com>
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [PATCH] lower-bitint: Handle INTEGER_CST rhs1 in handle_cast [PR113462]
Date: Sat, 20 Jan 2024 12:11:10 +0100	[thread overview]
Message-ID: <7E6ACD0B-8D1F-4653-9AFB-AF65E38B4FBA@suse.de> (raw)
In-Reply-To: <ZauUjO7HYqbIsIw+@tucnak>



> Am 20.01.2024 um 10:39 schrieb Jakub Jelinek <jakub@redhat.com>:
> 
> Hi!
> 
> The following patch ICEs because fre3 leaves around unfolded
>  _1 = VIEW_CONVERT_EXPR<_BitInt(129)>(0);

Hmm, const_unop should handle this, I suppose either we fail to convert this to a NOP_EXPR or native encode/interpret do not handle it?

Richard 

> statement and in handle_cast I was expecting just SSA_NAMEs for the
> large/huge _BitInt to large/huge _BitInt casts; INTEGER_CST is something
> we can handle in that case exactly the same, as the handle_operand recursion
> handles those.
> 
> Of course, maybe we should also try to fold_stmt such cases somewhere in
> bitint lowering preparation.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

Ok

Richard 

> 2024-01-20  Jakub Jelinek  <jakub@redhat.com>
> 
>    PR tree-optimization/113462
>    * gimple-lower-bitint.cc (bitint_large_huge::handle_cast):
>    Handle rhs1 INTEGER_CST like SSA_NAME.
> 
>    * gcc.dg/bitint-76.c: New test.
> 
> --- gcc/gimple-lower-bitint.cc.jj    2024-01-19 10:01:37.696673929 +0100
> +++ gcc/gimple-lower-bitint.cc    2024-01-19 18:36:34.175254308 +0100
> @@ -1250,7 +1250,7 @@ bitint_large_huge::handle_cast (tree lhs
> {
>   tree rhs_type = TREE_TYPE (rhs1);
>   gimple *g;
> -  if (TREE_CODE (rhs1) == SSA_NAME
> +  if ((TREE_CODE (rhs1) == SSA_NAME || TREE_CODE (rhs1) == INTEGER_CST)
>       && TREE_CODE (lhs_type) == BITINT_TYPE
>       && TREE_CODE (rhs_type) == BITINT_TYPE
>       && bitint_precision_kind (lhs_type) >= bitint_prec_large
> --- gcc/testsuite/gcc.dg/bitint-76.c.jj    2024-01-19 18:39:23.883980766 +0100
> +++ gcc/testsuite/gcc.dg/bitint-76.c    2024-01-19 18:38:48.758451335 +0100
> @@ -0,0 +1,16 @@
> +/* PR tree-optimization/113462 */
> +/* { dg-do compile { target bitint } } */
> +/* { dg-options "-std=c23 -O2" } */
> +
> +#if __BITINT_MAXWIDTH__ >= 129
> +typedef _BitInt(129) B;
> +#else
> +typedef _BitInt(63) B;
> +#endif
> +
> +B
> +foo (void)
> +{
> +  struct { B b; } s = {};
> +  return s.b;
> +}
> 
>    Jakub
> 

  reply	other threads:[~2024-01-20 11:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-20  9:38 Jakub Jelinek
2024-01-20 11:11 ` Richard Biener [this message]
2024-01-20 11:31   ` Jakub Jelinek
2024-01-22  8:58     ` Richard Biener
2024-01-22 10:27       ` Richard Biener
2024-01-22 10:40         ` Jakub Jelinek
2024-01-22 10:56           ` Richard Biener
2024-01-22 11:33             ` [PATCH] fold-const: Fold larger VIEW_CONVERT_EXPRs [PR113462] Jakub Jelinek
2024-01-22 11:53               ` Richard Biener

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=7E6ACD0B-8D1F-4653-9AFB-AF65E38B4FBA@suse.de \
    --to=rguenther@suse.de \
    --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).