summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp
diff options
context:
space:
mode:
authorCraig Topper <craig.topper@intel.com>2020-07-22 16:19:38 -0700
committerCraig Topper <craig.topper@intel.com>2020-07-22 16:57:46 -0700
commitb2c65beb14b5983a09e6eb4df8d41f5ddba1d6eb (patch)
treefa966caa9d77bd62d186d85485afdd15c7c149b3 /llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp
parent19d9c0397e61f2fb59a22d7c699436133a409aea (diff)
[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.
Diffstat (limited to 'llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp')
0 files changed, 0 insertions, 0 deletions