This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug rtl-optimization/59429] Missed optimization opportunity in qsort-style comparison functions
- From: "law at redhat dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Fri, 02 May 2014 16:33:53 +0000
- Subject: [Bug rtl-optimization/59429] Missed optimization opportunity in qsort-style comparison functions
- Auto-submitted: auto-generated
- References: <bug-59429-4 at http dot gcc dot gnu dot org/bugzilla/>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
--- Comment #10 from Jeffrey A. Law <law at redhat dot com> ---
So if you go into a cascaded if-else form, don't we have to recover the
COND_EXPR form to get good code?
Remember, that to get good code here, we need to discover a non-branching form
of one (or more) COND/COND_EXPR expressions and we'd really like to avoid
arithmetic in that non-branching form. ie, do a comparison and use the result
after casting it from a bool to a suitable integer type.
So I guess whatever form we want ought to be driven by which is easier to
analyze/rewrite into a COND_EXPR form that will be expanded into a setcc insn
without any arithmetic on the result.