[x86] Introduce a pass to begin more systematically fixing PR36028 and similar issues.
authorChandler Carruth <chandlerc@gmail.com>
Tue, 10 Apr 2018 01:41:17 +0000 (01:41 +0000)
committerChandler Carruth <chandlerc@gmail.com>
Tue, 10 Apr 2018 01:41:17 +0000 (01:41 +0000)
commit19618fc639978ac15086ab7448e529d4e3fbb49f
treee44d1cd0dc5827c055d71600aea141665676f6d0
parent0cdc6ec5357e9295dcd7bb0ce2a5e1fc5973626f
[x86] Introduce a pass to begin more systematically fixing PR36028 and similar issues.

The key idea is to lower COPY nodes populating EFLAGS by scanning the
uses of EFLAGS and introducing dedicated code to preserve the necessary
state in a GPR. In the vast majority of cases, these uses are cmovCC and
jCC instructions. For such cases, we can very easily save and restore
the necessary information by simply inserting a setCC into a GPR where
the original flags are live, and then testing that GPR directly to feed
the cmov or conditional branch.

However, things are a bit more tricky if arithmetic is using the flags.
This patch handles the vast majority of cases that seem to come up in
practice: adc, adcx, adox, rcl, and rcr; all without taking advantage of
partially preserved EFLAGS as LLVM doesn't currently model that at all.

There are a large number of operations that techinaclly observe EFLAGS
currently but shouldn't in this case -- they typically are using DF.
Currently, they will not be handled by this approach. However, I have
never seen this issue come up in practice. It is already pretty rare to
have these patterns come up in practical code with LLVM. I had to resort
to writing MIR tests to cover most of the logic in this pass already.
I suspect even with its current amount of coverage of arithmetic users
of EFLAGS it will be a significant improvement over the current use of
pushf/popf. It will also produce substantially faster code in most of
the common patterns.

This patch also removes all of the old lowering for EFLAGS copies, and
the hack that forced us to use a frame pointer when EFLAGS copies were
found anywhere in a function so that the dynamic stack adjustment wasn't
a problem. None of this is needed as we now lower all of these copies
directly in MI and without require stack adjustments.

Lots of thanks to Reid who came up with several aspects of this
approach, and Craig who helped me work out a couple of things tripping
me up while working on this.

Differential Revision: https://reviews.llvm.org/D45146

llvm-svn: 329657
21 files changed:
llvm/include/llvm/CodeGen/MachineBasicBlock.h
llvm/lib/CodeGen/MachineBasicBlock.cpp
llvm/lib/Target/X86/CMakeLists.txt
llvm/lib/Target/X86/X86.h
llvm/lib/Target/X86/X86FlagsCopyLowering.cpp [new file with mode: 0644]
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/lib/Target/X86/X86ISelLowering.h
llvm/lib/Target/X86/X86InstrInfo.cpp
llvm/lib/Target/X86/X86TargetMachine.cpp
llvm/test/CodeGen/X86/GlobalISel/add-scalar.ll
llvm/test/CodeGen/X86/O0-pipeline.ll
llvm/test/CodeGen/X86/O3-pipeline.ll
llvm/test/CodeGen/X86/clobber-fi0.ll [deleted file]
llvm/test/CodeGen/X86/cmpxchg-clobber-flags.ll
llvm/test/CodeGen/X86/copy-eflags.ll
llvm/test/CodeGen/X86/eflags-copy-expansion.mir [deleted file]
llvm/test/CodeGen/X86/flags-copy-lowering.mir [new file with mode: 0644]
llvm/test/CodeGen/X86/mul-i1024.ll
llvm/test/CodeGen/X86/peephole-na-phys-copy-folding.ll
llvm/test/CodeGen/X86/win64_frame.ll
llvm/test/CodeGen/X86/x86-repmov-copy-eflags.ll