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.
jeff
