[PATCH] D15157: CodeGen peephole: fold redundant phys reg copies

[JF Bastien via llvm-commits]

jfb created this revision.
jfb added a subscriber: llvm-commits.

Code generation often exposes redundant physical register copies through
virtual registers such as:

  %vreg = COPY %PHYSREG
  ...
  %PHYSREG = COPY %vreg

There are cases where no intervening clobber of %PHYSREG occurs, and the
later copy could therefore be removed. In some cases this further allows
us to remove the initial copy.

This patch contains a motivating example which comes from the x86 build
of Chrome, specifically cc::ResourceProvider::UnlockForRead uses
libstdc++'s implementation of hash_map. That example has two tests live
at the same time, and after machine sinking LLVM has confused itself
enough and things spilling EFLAGS is a great idea even though it's
never restored and the comparison results are both live.

Before this patch we have:
  DEC32m %RIP, 1, %noreg, <ga:@L>, %noreg, %EFLAGS<imp-def>
  %vreg1<def> = COPY %EFLAGS; GR64:%vreg1
  %EFLAGS<def> = COPY %vreg1; GR64:%vreg1
  JNE_1 <BB#1>, %EFLAGS<imp-use>

Both copies are useless. This patch tries to eliminate the later copy in
a generic manner.

dec is especially confusing to LLVM when compared with sub.

I wrote this patch to treat all physical registers generically, and it
seems like the x86 backend doesn't like this in other places.

This works fine with multiple physical register copies:
  test/ExecutionEngine/frem.ll

As well as when there are intervening calls between flag generation and
flag usage (these calls clobber flags):
  test/CodeGen/X86/cmpxchg-clobber-flags.ll

But the following tests unfortunately still fail:
  CodeGen/X86/StackColoring.ll
  CodeGen/X86/avx512-calling-conv.ll
  CodeGen/X86/copy-propagation.ll
  CodeGen/X86/inline-asm-fpstack.ll
  CodeGen/X86/musttail-varargs.ll
  CodeGen/X86/pop-stack-cleanup.ll
  CodeGen/X86/preserve_mostcc64.ll
  CodeGen/X86/tailcallstack64.ll
  CodeGen/X86/this-return-64.ll

Note that all other backends' tests pass.

I looked at some of the failures:
 * Sometimes these useless copies denote dependency breakage (e.g. see
   r235647 where a vxor is added before a def of xmm0 by vcvtsi2sd to
   break a dependency).
 * Sometimes these useless copies of the x87 FP stack have some effects
   I don't quite grok.

I'd appreciate some guidance in how to move forward.

http://reviews.llvm.org/D15157

Files:
  lib/CodeGen/PeepholeOptimizer.cpp
  test/CodeGen/X86/incdec-and-branch.ll

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D15157.41642.patch
Type: text/x-patch
Size: 9307 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151202/6f28dc7b/attachment.bin>