public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r11-8139] combine: Don't fold away side-effects in simplify_and_const_int_1 [PR99830] Date: Mon, 12 Apr 2021 23:01:21 +0000 (GMT) [thread overview] Message-ID: <20210412230121.9FBD4385781F@sourceware.org> (raw) https://gcc.gnu.org/g:9c1c8ad8339d551ac91a7af5614f29b9a687189a commit r11-8139-g9c1c8ad8339d551ac91a7af5614f29b9a687189a Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Apr 13 01:00:48 2021 +0200 combine: Don't fold away side-effects in simplify_and_const_int_1 [PR99830] Here is an alternate patch for the PR99830 bug. As discussed on IRC and in the PR, the reason why a (clobber:TI (const_int 0)) has been propagated into the debug insns is that it got optimized away during simplification from the i3 instruction pattern. And that happened because simplify_and_const_int_1 (SImode, varop, 255) with varop of (ashift:SI (subreg:SI (and:TI (clobber:TI (const_int 0 [0])) (const_int 255 [0xff])) 0) (const_int 16 [0x10])) was called and through nonzero_bits determined that (whatever << 16) & 255 is const0_rtx. It is, but if there are side-effects in varop and such clobbers are considered as such, we shouldn't optimize those away. 2021-04-13 Jakub Jelinek <jakub@redhat.com> PR debug/99830 * combine.c (simplify_and_const_int_1): Don't optimize varop away if it has side-effects. * gcc.dg/pr99830.c: New test. Diff: --- gcc/combine.c | 2 +- gcc/testsuite/gcc.dg/pr99830.c | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/gcc/combine.c b/gcc/combine.c index 3294575357b..dffa3b0390b 100644 --- a/gcc/combine.c +++ b/gcc/combine.c @@ -10153,7 +10153,7 @@ simplify_and_const_int_1 (scalar_int_mode mode, rtx varop, constop &= nonzero; /* If we don't have any bits left, return zero. */ - if (constop == 0) + if (constop == 0 && !side_effects_p (varop)) return const0_rtx; /* If VAROP is a NEG of something known to be zero or 1 and CONSTOP is diff --git a/gcc/testsuite/gcc.dg/pr99830.c b/gcc/testsuite/gcc.dg/pr99830.c new file mode 100644 index 00000000000..75226f5c3a9 --- /dev/null +++ b/gcc/testsuite/gcc.dg/pr99830.c @@ -0,0 +1,10 @@ +/* PR debug/99830 */ +/* { dg-do compile { target int128 } } */ +/* { dg-options "-O2 -fno-expensive-optimizations -fno-split-wide-types -g" } */ + +int foo (long a, __int128 b, short c, int d, unsigned e, __int128 f) +{ + __builtin_memmove (2 + (char *) &f, foo, 1); + c >>= (char) f; + return c; +}
reply other threads:[~2021-04-12 23:01 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20210412230121.9FBD4385781F@sourceware.org \ --to=jakub@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /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: linkBe 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).