public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "wangfeng at eswincomputing dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug rtl-optimization/109592] Failure to recognize shifts as sign/zero extension Date: Thu, 11 May 2023 07:56:29 +0000 [thread overview] Message-ID: <bug-109592-4-qfIP4Ve93U@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109592-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109592 --- Comment #5 from Feng Wang <wangfeng at eswincomputing dot com> --- I found something interesting, these operations such as zero_extend,sign_extend,zero_extract,sign_extract will be considered as compound operation and will transform to the approriate shifts and AND operations(This proc is in expand_compound_operation). So if the sign_extend op generated earlier,it will be converted by expand_compound_operation again during the after pass such as combine pass. In the combine pass, it will perform the opposite operation as above.Through make_compound and make_extraction functions two shifts insns will combine into sign_extend or zero_extend if the pattern exist,and then judge the cost of it.It is profitable replacement only when the arch supports sign_extend and costs less than two shifts insns. So I think the first patch is enough, https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg303789.html it handles the introduction of subregs when compiling and processing 32-bit using a 64 bit compiler. The first patch process the below rtl. (set (reg:SI 137) (ashiftrt:SI (subreg:SI (ashift:DI (reg:DI 140) (const_int 24 [0x18])) 0) (const_int 24 [0x18]))) During extract_left_shift processing,it wants to get reg:DI 140,but now the extraction is failed due to the subreg is in the front of the ashift. So I think we just need jump the subreg is enough to ensure normal subsequent processing.
next prev parent reply other threads:[~2023-05-11 7:56 UTC|newest] Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-04-22 0:12 [Bug rtl-optimization/109592] New: " law at gcc dot gnu.org 2023-04-24 2:46 ` [Bug rtl-optimization/109592] " wangfeng at eswincomputing dot com 2023-04-24 3:52 ` wangfeng at eswincomputing dot com 2023-04-24 7:02 ` rguenth at gcc dot gnu.org 2023-04-28 20:26 ` law at gcc dot gnu.org 2023-05-11 7:56 ` wangfeng at eswincomputing dot com [this message] 2023-05-11 14:33 ` law at gcc dot gnu.org 2023-05-29 16:35 ` law at gcc dot gnu.org 2023-05-30 6:17 ` wangfeng at eswincomputing dot com 2023-05-30 20:40 ` law at gcc dot gnu.org 2023-05-30 20:41 ` 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-109592-4-qfIP4Ve93U@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).