On Fri, May 12, 2017 at 9:09 PM, Uros Bizjak <ubiz...@gmail.com> wrote: > On Fri, May 12, 2017 at 8:34 PM, Jeff Law <l...@redhat.com> wrote: >> On 05/10/2017 01:05 PM, Uros Bizjak wrote: >>> >>> On Wed, May 10, 2017 at 5:18 PM, Uros Bizjak <ubiz...@gmail.com> wrote: >>>> >>>> On Wed, May 10, 2017 at 4:27 PM, Jakub Jelinek <ja...@redhat.com> wrote: >>>>> >>>>> On Tue, May 09, 2017 at 06:06:47PM +0200, Uros Bizjak wrote: >>>>>> >>>>>> Attached patch enables post-reload compare elimination pass by >>>>>> providing expected patterns (duplicates of existing patterns with >>>>>> setters of reg and flags switched in the parallel) for flag setting >>>>>> arithmetic instructions. >>>>>> >>>>>> The merge triggers more than 3000 times during the gcc bootstrap, >>>>>> mostly in cases where intervening memory load or store prevents >>>>>> combine from merging the arithmetic insn and the following compare. >>>>>> >>>>>> Also, some recent linux x86_64 defconfig build results in ~200 merges, >>>>>> removing ~200 test/cmp insns. Not much, but I think the results still >>>>>> warrant the pass to be enabled. >>>>> >>>>> >>>>> Isn't the right fix instead to change the compare-elim.c pass to either >>>>> accept both reg vs. flags orderings in parallel, or both depending >>>>> on some target hook, or change it to the order i386.md and most other >>>>> major targets use and just fix up mn10300/rx (and aarch64?) to use the >>>>> same >>>>> order? >>> >>> >>> Attached patch changes compare-elim.c order to what i386.md expects. >>> >>> Thoughts? >> >> I think with an appropriate change to the canonicalization rules in the >> manual this is fine. >> >> I've got the visium, rx and mn103 patches handy to ensure they don't >> regress. aarch64 doesn't seem to be affected either way but I didn't >> investigate why -- I expected it to improve with your change. >> >> I'll write up a ChangeLog and commit the mn103, rx and visium changes after >> you commit the compare-elim & documentation bits.
Something like the attached patch? 2017-05-12 Uros Bizjak <ubiz...@gmail.com> * doc/md.texi ( Canonicalization of Instructions): Describe the canonical form of instructions that inherently set a condition code register. Uros.
Index: doc/md.texi =================================================================== --- doc/md.texi (revision 247980) +++ doc/md.texi (working copy) @@ -7258,6 +7258,25 @@ if the first argument is a condition code register or @code{(cc0)}. @item +For instructions that inherently set a condition code register, the +@code{compare} operator is always written as the first RTL expression of +the @code{parallel} instruction pattern. For example, + +@smallexample +(define_insn "" + [(set (reg:CCZ FLAGS_REG) + (compare:CCZ + (plus:SI + (match_operand:SI 1 "register_operand" "%r") + (match_operand:SI 2 "register_operand" "r")) + (const_int 0))) + (set (match_operand:SI 0 "register_operand" "=r") + (plus:SI (match_dup 1) (match_dup 2)))] + "" + "addl %0, %1, %2") +@end smallexample + +@item An operand of @code{neg}, @code{not}, @code{mult}, @code{plus}, or @code{minus} is made the first operand under the same conditions as above.