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
>
next prev parent 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).