[all-commits] [llvm/llvm-project] b2c65b: [X86] Rework the "sahf" feature flag to only apply...

[topperc via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: b2c65beb14b5983a09e6eb4df8d41f5ddba1d6eb
      https://github.com/llvm/llvm-project/commit/b2c65beb14b5983a09e6eb4df8d41f5ddba1d6eb
  Author: Craig Topper <craig.topper at intel.com>
  Date:   2020-07-22 (Wed, 22 Jul 2020)

  Changed paths:
    M llvm/lib/Target/X86/X86.td
    M llvm/lib/Target/X86/X86Subtarget.cpp
    M llvm/lib/Target/X86/X86Subtarget.h
    M llvm/test/CodeGen/X86/setuge.ll

  Log Message:
  -----------
  [X86] Rework the "sahf" feature flag to only apply to 64-bit mode.

SAHF/LAHF instructions are always available in 32-bit mode. Early
64-bit capable CPUs made the undefined opcodes in 64-bit mode. This
was changed on later CPUs.

We have a feature flag to control our usage of these instructions.
This feature flag is hooked up to a clang command line option
-msahf/-mno-sahf specifically to give control of the 64-bit mode
behavior.

In the backend X86Subtarget constructor we were explicitly forcing
+sahf into the feature flag string if we were not compiling for
64-bit mode. This was intended to make the predicates always allow
the instructions outside of 64-bit mode. Unfortunately, the way
it was placed into the string allowed -mno-sahf from clang to disable
SAHF instructions in 32-bit mode. This causes an assertion to fire
if you compile a floating point comparison with something like
"-march=pentium -mno-sahf" as our floating point comparison
handling on CPUs that don't support FCOMI/FUCOMI instructions
requires SAHF.

To fix this, this commit restricts the feature flag to only apply to
64-bit mode by ignoring the flag outside 64-bit mode in
X86Subtarget::hasLAHFSAHF(). This way we don't need to mess with
the feature string at all.