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 tree-optimization/106888] [RISCV] Negative optimization that excess andi instructions are generated in gcc.dg/pr90838.c
Date: Sat, 22 Apr 2023 00:08:55 +0000 [thread overview]
Message-ID: <bug-106888-4-WxnAknBELM@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-106888-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106888
--- Comment #9 from Vineet Gupta <vineetg at gcc dot gnu.org> ---
(In reply to Jeffrey A. Law from comment #6)
> Comment on attachment 54905 [details]
> proposed patch
>
> So that's a subset of what we've done. We initially thought that was going
> to be enough to solve this class of problems. But it's actually deeper
> than just having a zero_extension variant of this pattern.
Yeah it seems adding a new define_insn with zero_extend is not enough (nor is
the more elegant any_extend to existing "*<bitmanip_optab>disi2")
Thing is at expand time, we have gimple CTZ expand to ctz+sign_extend, so
adding zero_extend won't really help ?
(insn 6 3 7 2 (set (reg:SI 74)
(ctz:SI (subreg/s/u:SI (reg/v:DI 73 [ x ]) 0))) "pr90838-red.c":11:15
-1
(nil))
(insn 7 6 8 2 (set (reg:DI 72 [ <retval> ])
(sign_extend:DI (reg:SI 74))) "pr90838-red.c":11:15 -1
(nil))
> I'll officially submit the zero_extension pattern and the match.pd bits.
> The other pattern we wrote is fugly and I'd like to look at it one more time.
But that other pattern is needed for combine to fuse them together.
next prev parent reply other threads:[~2023-04-22 0:08 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-09-08 9:36 [Bug regression/106888] New: [RISCV] Excess " shihua at iscas dot ac.cn
2022-09-08 9:46 ` [Bug tree-optimization/106888] [RISCV] Negative optimization that excess " shihua at iscas dot ac.cn
2023-04-20 19:00 ` pinskia at gcc dot gnu.org
2023-04-20 23:06 ` vineetg at gcc dot gnu.org
2023-04-20 23:44 ` law at gcc dot gnu.org
2023-04-21 17:27 ` roger at nextmovesoftware dot com
2023-04-21 17:38 ` law at gcc dot gnu.org
2023-04-21 21:18 ` vineetg at gcc dot gnu.org
2023-04-21 22:07 ` law at gcc dot gnu.org
2023-04-22 0:08 ` vineetg at gcc dot gnu.org [this message]
2023-04-22 0:16 ` law at gcc dot gnu.org
2023-05-20 2:55 ` cvs-commit at gcc dot gnu.org
2023-05-20 3:03 ` law 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-106888-4-WxnAknBELM@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: 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).