diff options
| author | Craig Topper <craig.topper@intel.com> | 2020-07-22 16:19:38 -0700 |
|---|---|---|
| committer | Craig Topper <craig.topper@intel.com> | 2020-07-22 16:57:46 -0700 |
| commit | b2c65beb14b5983a09e6eb4df8d41f5ddba1d6eb (patch) | |
| tree | fa966caa9d77bd62d186d85485afdd15c7c149b3 /llvm/lib/Bitcode/Reader/BitcodeAnalyzer.cpp | |
| parent | 19d9c0397e61f2fb59a22d7c699436133a409aea (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
