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?
I was looking at compare-elim.c, where in line 675 function try_eliminate_compare simply substitutes clobber of CC-reg with a new compare RTX through a validate_change call. I'm not sure, what would be the best way to handle both insn variants here. I was hoping perhaps Jeff would help with the correct approach. Additional copy of several patterns indeed seems heavily counter-productive. > I think this has been discussed before already several times. True, but there was no resolution. As an experiment, I was surprised, how many cases patched compiler caught, even with the limited set of additional patterns. So, the postreload cmpelim pass certainly brings some benefits, in the same sense postreload ree pass does, to catch additional opportunities that combine pass wasn't able to merge. Uros.
