public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "vineetg at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/110748] RISC-V: optimize store of DF 0.0 Date: Thu, 20 Jul 2023 17:24:39 +0000 [thread overview] Message-ID: <bug-110748-4-fkob0WBJdR@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-110748-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110748 --- Comment #8 from Vineet Gupta <vineetg at gcc dot gnu.org> --- (In reply to Jeffrey A. Law from comment #5) > I'd bet it's const_0_operand not allowing CONST_DOUBLE. Correct. > The question is what unintended side effects we'd have if we allowed > CONST_DOUBLE 0.0 in const_0_operand. Exactly. I had the same concern. I do have a hack which creates a new predicate and that seems to do the trick. +(define_predicate "const_0hf_operand" + (and (match_code "const_double") + (match_test "op == CONST0_RTX (GET_MODE (op))"))) + +(define_predicate "reg_or_0_operand_inc_hf" + (ior (match_operand 0 "reg_or_0_operand") + (match_operand 0 "const_0hf_operand"))) diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc - if (!register_operand (dest, mode) && !reg_or_0_operand (src, mode)) + if (!register_operand (dest, mode) && !reg_or_0_operand_inc_hf (src, mode)) { And it seems to be generating the desired int 0 for double 0.0. However to Kito's point, this indeed works in gcc 12 so I first need to bisect what regressed it in 13.
next prev parent reply other threads:[~2023-07-20 17:24 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-07-20 6:13 [Bug target/110748] New: " vineetg at gcc dot gnu.org 2023-07-20 6:15 ` [Bug target/110748] RISC-V: " vineetg at gcc dot gnu.org 2023-07-20 6:28 ` kito at gcc dot gnu.org 2023-07-20 6:33 ` kito at gcc dot gnu.org 2023-07-20 6:50 ` vineetg at gcc dot gnu.org 2023-07-20 16:07 ` pinskia at gcc dot gnu.org 2023-07-20 16:23 ` law at gcc dot gnu.org 2023-07-20 17:13 ` palmer at gcc dot gnu.org 2023-07-20 17:22 ` palmer at gcc dot gnu.org 2023-07-20 17:24 ` vineetg at gcc dot gnu.org [this message] 2023-07-20 17:38 ` vineetg at gcc dot gnu.org 2023-07-21 21:29 ` vineetg at gcc dot gnu.org 2023-07-21 21:40 ` vineetg at gcc dot gnu.org 2023-07-21 21:44 ` vineetg at gcc dot gnu.org 2023-07-21 22:51 ` pinskia at gcc dot gnu.org 2023-07-22 21:45 ` cvs-commit at gcc dot gnu.org 2023-07-28 23:22 ` vineetg at gcc dot gnu.org 2023-08-15 17:13 ` vineetg at gcc dot gnu.org
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=bug-110748-4-fkob0WBJdR@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@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).