public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "richard.yao at alumni dot stonybrook.edu" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug middle-end/109901] New: Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b)) Date: Thu, 18 May 2023 00:43:13 +0000 [thread overview] Message-ID: <bug-109901-4@http.gcc.gnu.org/bugzilla/> (raw) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109901 Bug ID: 109901 Summary: Optimization opportunity: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b)) Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: richard.yao at alumni dot stonybrook.edu Target Milestone: --- LLVM/Clang also misses this optimization opportunity, so I also filed an issue with them: https://github.com/llvm/llvm-project/issues/62790 The following transformations can be done as an optimization: ((((a) > (b)) - ((a) < (b))) < 0) -> ((a) < (b)) ((((a) > (b)) - ((a) < (b))) <= 0) -> ((a) <= (b)) ((((a) > (b)) - ((a) < (b))) == -1) -> ((a) < (b)) ((((a) > (b)) - ((a) < (b))) == 1) -> ((a) > (b)) ((((a) > (b)) - ((a) < (b))) == 0) -> ((a) == (b)) ((((a) > (b)) - ((a) < (b))) > 0) -> ((a) > (b)) ((((a) > (b)) - ((a) < (b))) >= 0) -> ((a) >= (b)) ((((a) >= (b)) - ((a) <= (b))) < 0) -> ((a) < (b)) ((((a) >= (b)) - ((a) <= (b))) <= 0) -> ((a) <= (b)) ((((a) >= (b)) - ((a) <= (b))) == -1) -> ((a) < (b)) ((((a) >= (b)) - ((a) <= (b))) == 1) -> ((a) > (b)) ((((a) >= (b)) - ((a) <= (b))) == 0) -> ((a) == (b)) ((((a) >= (b)) - ((a) <= (b))) > 0) -> ((a) > (b)) ((((a) >= (b)) - ((a) <= (b))) >= 0) -> ((a) >= (b)) Both (((a) > (b)) - ((a) < (b))) and (((a) >= (b)) - ((a) <= (b))) will generate -1, 0 or 1 when comparing two integers (signed or unsigned). When comparators using this trick are inlined into the caller, the above transformations become applicable. I noticed that neither compiler exploits this high level optimization opportunity when I was working on using a faster binary search implementation for the OpenZFS b-tree code. It relied on a macro to achieve C++-style inlining of the comparator into the implementation by making different versions of the same function. The following example at godbolt does not use a macro to make it easier to see which lines of assembly correspond to which lines of high level C: https://gcc.godbolt.org/z/cdedccxae On amd64, GCC generates 15 instructions for the loop. If you comment out line 35 and uncomment line 37, GCC will generate 11 instructions for the loop. This is the output GCC would produce if it supported that high level optimization. Had the comparator returned 1 for less than and 0 for greater than or equal to, we would have had the 11-instruction version of the loop without any need for this optimization. Changing the semantics because our compilers lack this optimization would be painful in part because the entire code base expects the -1, 0 or 1 return value semantics and other code depends on these comparators. It would be nice if GCC implemented this optimization.
next reply other threads:[~2023-05-18 0:43 UTC|newest] Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-18 0:43 richard.yao at alumni dot stonybrook.edu [this message] 2023-05-18 0:56 ` [Bug tree-optimization/109901] " pinskia at gcc dot gnu.org 2023-05-18 1:07 ` pinskia at gcc dot gnu.org 2023-05-18 1:08 ` pinskia at gcc dot gnu.org 2023-05-18 1:11 ` pinskia at gcc dot gnu.org 2023-05-18 1:12 ` pinskia at gcc dot gnu.org 2023-05-18 1:13 ` pinskia at gcc dot gnu.org 2023-05-18 1:43 ` richard.yao at alumni dot stonybrook.edu 2023-05-18 4:12 ` richard.yao at alumni dot stonybrook.edu 2023-05-27 3:33 ` richard.yao at alumni dot stonybrook.edu
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-109901-4@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).