maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/llvm/lib/Target/X86/X86Subtarget.cpp

432 lines
13 KiB
C++
Raw Normal View History

Initialize HasPOPCNT. llvm-svn: 120923
2010-12-05 07:57:24 +08:00
//===-- X86Subtarget.cpp - X86 Subtarget Information ----------------------===//
Implement Subtarget support Implement the X86 Subtarget. This consolidates the checks for target triple, and setting options based on target triple into one place. This allows us to convert the asm printer and isel over from being littered with "forDarwin", "forCygwin", etc. into just having the appropriate flags for each subtarget feature controlling the code for that feature. This patch also implements indirect external and weak references in the X86 pattern isel, for darwin. Next up is to convert over the asm printers to use this new interface. llvm-svn: 22389
2005-07-12 09:41:54 +08:00
//
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. llvm-svn: 45418
2007-12-30 04:36:04 +08:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Implement Subtarget support Implement the X86 Subtarget. This consolidates the checks for target triple, and setting options based on target triple into one place. This allows us to convert the asm printer and isel over from being littered with "forDarwin", "forCygwin", etc. into just having the appropriate flags for each subtarget feature controlling the code for that feature. This patch also implements indirect external and weak references in the X86 pattern isel, for darwin. Next up is to convert over the asm printers to use this new interface. llvm-svn: 22389
2005-07-12 09:41:54 +08:00
//
//===----------------------------------------------------------------------===//
//
Rename TargetSubtarget to TargetSubtargetInfo for consistency. llvm-svn: 134259
2011-07-02 05:01:15 +08:00
// This file implements the X86 specific subclass of TargetSubtargetInfo.
Implement Subtarget support Implement the X86 Subtarget. This consolidates the checks for target triple, and setting options based on target triple into one place. This allows us to convert the asm printer and isel over from being littered with "forDarwin", "forCygwin", etc. into just having the appropriate flags for each subtarget feature controlling the code for that feature. This patch also implements indirect external and weak references in the X86 pattern isel, for darwin. Next up is to convert over the asm printers to use this new interface. llvm-svn: 22389
2005-07-12 09:41:54 +08:00
//
//===----------------------------------------------------------------------===//
[X86] Move GISel accessor initialization from TargetMachine to Subtarget. NFC llvm-svn: 306921
2017-07-01 08:45:50 +08:00
#include "X86.h"
#include "X86CallLowering.h"
#include "X86LegalizerInfo.h"
#include "X86RegisterBankInfo.h"
Implement Subtarget support Implement the X86 Subtarget. This consolidates the checks for target triple, and setting options based on target triple into one place. This allows us to convert the asm printer and isel over from being littered with "forDarwin", "forCygwin", etc. into just having the appropriate flags for each subtarget feature controlling the code for that feature. This patch also implements indirect external and weak references in the X86 pattern isel, for darwin. Next up is to convert over the asm printers to use this new interface. llvm-svn: 22389
2005-07-12 09:41:54 +08:00
#include "X86Subtarget.h"
Sort the remaining #include lines in include/... and lib/.... I did this a long time ago with a janky python script, but now clang-format has built-in support for this. I fed clang-format every line with a #include and let it re-sort things according to the precise LLVM rules for include ordering baked into clang-format these days. I've reverted a number of files where the results of sorting includes isn't healthy. Either places where we have legacy code relying on particular include ordering (where possible, I'll fix these separately) or where we have particular formatting around #include lines that I didn't want to disturb in this patch. This patch is *entirely* mechanical. If you get merge conflicts or anything, just ignore the changes in this patch and run clang-format over your #include lines in the files. Sorry for any noise here, but it is important to keep these things stable. I was seeing an increasing number of patches with irrelevant re-ordering of #include lines because clang-format was used. This patch at least isolates that churn, makes it easy to skip when resolving conflicts, and gets us to a clean baseline (again). llvm-svn: 304787
2017-06-06 19:49:48 +08:00
#include "MCTargetDesc/X86BaseInfo.h"
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
#include "X86TargetMachine.h"
[X86] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 293949
2017-02-03 06:55:55 +08:00
#include "llvm/ADT/Triple.h"
[X86] Move GISel accessor initialization from TargetMachine to Subtarget. NFC llvm-svn: 306921
2017-07-01 08:45:50 +08:00
#include "llvm/CodeGen/GlobalISel/CallLowering.h"
#include "llvm/CodeGen/GlobalISel/InstructionSelect.h"
Use the 'target-features' and 'target-cpu' attributes to reset the subtarget features. If two functions require different features (e.g., `-mno-sse' vs. `-msse') then we want to honor that, especially during LTO. We can do that by resetting the subtarget's features depending upon the 'target-feature' attribute. llvm-svn: 175314
2013-02-16 06:31:27 +08:00
#include "llvm/IR/Attributes.h"
X86: Produce @ABS8 symbol modifiers for absolute symbols in range [0,128). Differential Revision: https://reviews.llvm.org/D28689 llvm-svn: 293844
2017-02-02 08:32:03 +08:00
#include "llvm/IR/ConstantRange.h"
Use the 'target-features' and 'target-cpu' attributes to reset the subtarget features. If two functions require different features (e.g., `-mno-sse' vs. `-msse') then we want to honor that, especially during LTO. We can do that by resetting the subtarget's features depending upon the 'target-feature' attribute. llvm-svn: 175314
2013-02-16 06:31:27 +08:00
#include "llvm/IR/Function.h"
Move all of the header files which are involved in modelling the LLVM IR into their new header subdirectory: include/llvm/IR. This matches the directory structure of lib, and begins to correct a long standing point of file layout clutter in LLVM. There are still more header files to move here, but I wanted to handle them in separate commits to make tracking what files make sense at each layer easier. The only really questionable files here are the target intrinsic tablegen files. But that's a battle I'd rather not fight today. I've updated both CMake and Makefile build systems (I think, and my tests think, but I may have missed something). I've also re-sorted the includes throughout the project. I'll be committing updates to Clang, DragonEgg, and Polly momentarily. llvm-svn: 171366
2013-01-02 19:36:10 +08:00
#include "llvm/IR/GlobalValue.h"
[X86] Fix some Clang-tidy modernize and Include What You Use warnings; other minor fixes (NFC). llvm-svn: 293949
2017-02-03 06:55:55 +08:00
#include "llvm/Support/Casting.h"
#include "llvm/Support/CodeGen.h"
Fix compilation issues. llvm-svn: 209342
2014-05-22 07:51:57 +08:00
#include "llvm/Support/CommandLine.h"
Fix PR3210: Detect more Intel processors. Patch by Torok Edwin. llvm-svn: 61602
2009-01-03 12:04:46 +08:00
#include "llvm/Support/Debug.h"
Detect attempt to use segmented stacks on non ELF systems and error (not assert) early. llvm-svn: 139233
2011-09-08 00:10:57 +08:00
#include "llvm/Support/ErrorHandling.h"
Use the new script to sort the includes of every file under lib. Sooooo many of these had incorrect or strange main module includes. I have manually inspected all of these, and fixed the main module include to be the nearest plausible thing I could find. If you own or care about any of these source files, I encourage you to take some time and check that these edits were sensible. I can't have broken anything (I strictly added headers, and reordered them, never removed), but they may not be the headers you'd really like to identify as containing the API being implemented. Many forward declarations and missing includes were added to a header files to allow them to parse cleanly when included first. The main module rule does in fact have its merits. =] llvm-svn: 169131
2012-12-04 00:50:05 +08:00
#include "llvm/Support/raw_ostream.h"
Refactored JIT codegen for mingw32. Now we're using standart relocation type for distinguish JIT & non-JIT instead of "dirty" hacks :) llvm-svn: 32745
2006-12-23 06:29:05 +08:00
#include "llvm/Target/TargetMachine.h"
- Added MCSubtargetInfo to capture subtarget features and scheduling itineraries. - Refactor TargetSubtarget to be based on MCSubtargetInfo. - Change tablegen generated subtarget info to initialize MCSubtargetInfo and hide more details from targets. llvm-svn: 134257
2011-07-02 04:45:01 +08:00
add support for detecting process features on win64, patch by Nicolas Capens! llvm-svn: 70057
2009-04-26 02:27:23 +08:00
#if defined(_MSC_VER)
- s/DOUT/DEBUG(errs()/g - Tidy up some headers. llvm-svn: 77929
2009-08-03 08:11:34 +08:00
#include <intrin.h>
add support for detecting process features on win64, patch by Nicolas Capens! llvm-svn: 70057
2009-04-26 02:27:23 +08:00
#endif
[Modules] Fix potential ODR violations by sinking the DEBUG_TYPE definition below all of the header #include lines, lib/Target/... edition. llvm-svn: 206842
2014-04-22 10:41:26 +08:00
using namespace llvm;
#define DEBUG_TYPE "subtarget"
[cleanup] Lift using directives, DEBUG_TYPE definitions, and even some system headers above the includes of generated '.inc' files that actually contain code. In a few targets this was already done pretty consistently, but it wasn't done *really* consistently anywhere. It is strictly cleaner IMO and necessary in a bunch of places where the DEBUG_TYPE is referenced from the generated code. Consistency with the necessary places trumps. Hopefully the build bots are OK with the movement of intrin.h... llvm-svn: 206838
2014-04-22 10:03:14 +08:00
#define GET_SUBTARGETINFO_TARGET_DESC
#define GET_SUBTARGETINFO_CTOR
#include "X86GenSubtargetInfo.inc"
Make early if conversion dependent upon the subtarget and add a subtarget hook to enable. Unconditionally add to the pass pipeline for targets that might want to use it. No functional change. llvm-svn: 209340
2014-05-22 07:40:26 +08:00
// Temporary option to control early if-conversion for x86 while adding machine
// models.
static cl::opt<bool>
X86EarlyIfConv("x86-early-ifcvt", cl::Hidden,
cl::desc("Enable early if-conversion on X86"));
don't repeaat function names in comments; NFC llvm-svn: 245058
2015-08-14 23:11:42 +08:00
/// Classify a blockaddress reference for the current subtarget according to how
/// we should reference it in a non-pcrel context.
Style fixes. NFC. llvm-svn: 270093
2016-05-20 02:34:20 +08:00
unsigned char X86Subtarget::classifyBlockAddressReference() const {
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return classifyLocalReference(nullptr);
}
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
/// Classify a global variable reference for the current subtarget according to
/// how we should reference it in a non-pcrel context.
unsigned char
X86Subtarget::classifyGlobalReference(const GlobalValue *GV) const {
return classifyGlobalReference(GV, *GV->getParent());
}
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
unsigned char
X86Subtarget::classifyLocalReference(const GlobalValue *GV) const {
// 64 bits can use %rip addressing for anything local.
if (is64Bit())
return X86II::MO_NO_FLAG;
move some classification logic around. Now GVRequiresExtraLoad is just a trivial wrapper around "ClassifyGlobalReference", which stole a ton of logic from LowerGlobalAddress. llvm-svn: 75237
2009-07-10 15:20:05 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
// If this is for a position dependent executable, the static linker can
// figure it out.
[X86Subtarget] Use isPositionIndependent(). NFC. Differential Revision: http://reviews.llvm.org/D21480 llvm-svn: 273071
2016-06-18 08:03:20 +08:00
if (!isPositionIndependent())
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return X86II::MO_NO_FLAG;
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
// The COFF dynamic linker just patches the executable sections.
if (isTargetCOFF())
return X86II::MO_NO_FLAG;
if (isTargetDarwin()) {
// 32 bit macho has no relocation for a-b if a is undefined, even if
// b is in the section that is being relocated.
// This means we have to use o load even for GVs that are known to be
// local to the dso.
if (GV && (GV->isDeclarationForLinker() || GV->hasCommonLinkage()))
Simplify handling of hidden stub. Since r207518 they are printed exactly like non-hidden stubs on x86 and since r207517 on ARM. This means we can use a single set for all stubs in those platforms. llvm-svn: 269776
2016-05-18 00:01:32 +08:00
return X86II::MO_DARWIN_NONLAZY_PIC_BASE;
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
some minor simplifications. llvm-svn: 75274
2009-07-11 04:53:38 +08:00
return X86II::MO_PIC_BASE_OFFSET;
}
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return X86II::MO_GOTOFF;
}
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
unsigned char X86Subtarget::classifyGlobalReference(const GlobalValue *GV,
const Module &M) const {
// Large model never uses stubs.
if (TM.getCodeModel() == CodeModel::Large)
return X86II::MO_NO_FLAG;
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
IR, X86: Understand !absolute_symbol metadata on global variables. Summary: Attaching !absolute_symbol to a global variable does two things: 1) Marks it as an absolute symbol reference. 2) Specifies the value range of that symbol's address. Teach the X86 backend to allow absolute symbols to appear in place of immediates by extending the relocImm and mov64imm32 matchers. Start using relocImm in more places where it is legal. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html Differential Revision: https://reviews.llvm.org/D25878 llvm-svn: 289087
2016-12-09 03:01:00 +08:00
// Absolute symbols can be referenced directly.
X86: Produce @ABS8 symbol modifiers for absolute symbols in range [0,128). Differential Revision: https://reviews.llvm.org/D28689 llvm-svn: 293844
2017-02-02 08:32:03 +08:00
if (GV) {
if (Optional<ConstantRange> CR = GV->getAbsoluteSymbolRange()) {
// See if we can use the 8-bit immediate form. Note that some instructions
// will sign extend the immediate operand, so to be conservative we only
// accept the range [0,128).
if (CR->getUnsignedMax().ult(128))
return X86II::MO_ABS8;
else
return X86II::MO_NO_FLAG;
}
}
IR, X86: Understand !absolute_symbol metadata on global variables. Summary: Attaching !absolute_symbol to a global variable does two things: 1) Marks it as an absolute symbol reference. 2) Specifies the value range of that symbol's address. Teach the X86 backend to allow absolute symbols to appear in place of immediates by extending the relocImm and mov64imm32 matchers. Start using relocImm in more places where it is legal. As previously proposed on llvm-dev: http://lists.llvm.org/pipermail/llvm-dev/2016-October/105800.html Differential Revision: https://reviews.llvm.org/D25878 llvm-svn: 289087
2016-12-09 03:01:00 +08:00
Handle undefined weak hidden symbols on all architectures. We were handling the non-hidden case in lib/Target/TargetMachine.cpp, but the hidden case was handled in architecture dependent code and only X86_64 and AArch64 were covered. While it is true that some code sequences in some ABIs might be able to produce the correct value at runtime, that doesn't seem to be the common case. I left the AArch64 code in place since it also forces a got access for non-pic code. It is not clear if that is needed, but it is probably better to change that in another commit. llvm-svn: 316799
2017-10-28 05:18:48 +08:00
if (TM.shouldAssumeDSOLocal(M, GV))
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return classifyLocalReference(GV);
Reference to hidden symbols do not have to go through non-lazy pointer in non-pic mode. rdar://7187172. llvm-svn: 80904
2009-09-03 15:04:02 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
if (isTargetCOFF())
return X86II::MO_DLLIMPORT;
if (is64Bit())
return X86II::MO_GOTPCREL;
if (isTargetDarwin()) {
[X86Subtarget] Use isPositionIndependent(). NFC. Differential Revision: http://reviews.llvm.org/D21480 llvm-svn: 273071
2016-06-18 08:03:20 +08:00
if (!isPositionIndependent())
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return X86II::MO_DARWIN_NONLAZY;
return X86II::MO_DARWIN_NONLAZY_PIC_BASE;
move some classification logic around. Now GVRequiresExtraLoad is just a trivial wrapper around "ClassifyGlobalReference", which stole a ton of logic from LowerGlobalAddress. llvm-svn: 75237
2009-07-10 15:20:05 +08:00
}
Whitespace. llvm-svn: 161122
2012-08-02 02:39:17 +08:00
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return X86II::MO_GOT;
move some classification logic around. Now GVRequiresExtraLoad is just a trivial wrapper around "ClassifyGlobalReference", which stole a ton of logic from LowerGlobalAddress. llvm-svn: 75237
2009-07-10 15:20:05 +08:00
}
Remember the relocation model. NFC. This avoids passing a TargetMachine in a few places. llvm-svn: 270095
2016-05-20 02:49:29 +08:00
unsigned char
X86Subtarget::classifyGlobalFunctionReference(const GlobalValue *GV) const {
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return classifyGlobalFunctionReference(GV, *GV->getParent());
}
unsigned char
X86Subtarget::classifyGlobalFunctionReference(const GlobalValue *GV,
const Module &M) const {
Move shouldAssumeDSOLocal to Target. Should fix the shared library build. llvm-svn: 273958
2016-06-28 07:15:57 +08:00
if (TM.shouldAssumeDSOLocal(M, GV))
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
return X86II::MO_NO_FLAG;
[X86] Teach fastisel to select calls to dllimport functions Summary: Direct calls to dllimport functions are very common Windows. We should add them to the -O0 fast path. Reviewers: rafael Subscribers: llvm-commits, hiraditya Differential Revision: https://reviews.llvm.org/D36197 llvm-svn: 310152
2017-08-05 08:10:43 +08:00
if (isTargetCOFF()) {
assert(GV->hasDLLImportStorageClass() &&
"shouldAssumeDSOLocal gave inconsistent answer");
return X86II::MO_DLLIMPORT;
}
Attribute nonlazybind should not affect calls to functions with hidden visibility. Differential Revision: https://reviews.llvm.org/D39625 llvm-svn: 317639
2017-11-08 08:01:05 +08:00
const Function *F = dyn_cast_or_null<Function>(GV);
[X86] Disabling PLT in Regcall CC Functions According to psABI, PLT stub clobbers XMM8-XMM15. In Regcall calling convention those registers are used for passing parameters. Thus we need to prevent lazy binding in Regcall. Differential Revision: https://reviews.llvm.org/D32430 llvm-svn: 302124
2017-05-04 15:22:49 +08:00
if (isTargetELF()) {
if (is64Bit() && F && (CallingConv::X86_RegCall == F->getCallingConv()))
// According to psABI, PLT stub clobbers XMM8-XMM15.
// In Regcall calling convention those registers are used for passing
// parameters. Thus we need to prevent lazy binding in Regcall.
return X86II::MO_GOTPCREL;
Intrinsics calls should avoid the PLT when "RtLibUseGOT" metadata is present. Differential Revision: https://reviews.llvm.org/D42216 llvm-svn: 325962
2018-02-24 05:32:06 +08:00
// If PLT must be avoided then the call should be via GOTPCREL.
if (((F && F->hasFnAttribute(Attribute::NonLazyBind)) ||
(!F && M.getRtLibUseGOT())) &&
is64Bit())
return X86II::MO_GOTPCREL;
[X86] enable PIE for functions Call locally defined function directly for PIE/fPIE Differential Revision: http://reviews.llvm.org/D19226 llvm-svn: 266863
2016-04-20 16:32:57 +08:00
return X86II::MO_PLT;
[X86] Disabling PLT in Regcall CC Functions According to psABI, PLT stub clobbers XMM8-XMM15. In Regcall calling convention those registers are used for passing parameters. Thus we need to prevent lazy binding in Regcall. Differential Revision: https://reviews.llvm.org/D32430 llvm-svn: 302124
2017-05-04 15:22:49 +08:00
}
Refactor X86 symbol access classification. This refactors the logic in X86 to avoid code duplication. It also splits it in two steps: it first decides if a symbol is local to the DSO and then uses that information to decide how to access it. The first part is implemented by shouldAssumeDSOLocal. It is not in any way specific to X86. In a followup patch I intend to move it to somewhere common and reused it in other backends. llvm-svn: 270209
2016-05-20 20:20:10 +08:00
if (is64Bit()) {
if (F && F->hasFnAttribute(Attribute::NonLazyBind))
// If the function is marked as non-lazy, generate an indirect call
// which loads from the GOT directly. This avoids runtime overhead
// at the cost of eager binding (and one extra byte of encoding).
return X86II::MO_GOTPCREL;
return X86II::MO_NO_FLAG;
[X86] enable PIE for functions Call locally defined function directly for PIE/fPIE Differential Revision: http://reviews.llvm.org/D19226 llvm-svn: 266863
2016-04-20 16:32:57 +08:00
}
return X86II::MO_NO_FLAG;
}
Factor out GVRequiresExtraLoad() from .h to .cpp llvm-svn: 32048
2006-12-01 06:42:55 +08:00
don't repeaat function names in comments; NFC llvm-svn: 245058
2015-08-14 23:11:42 +08:00
/// Return true if the subtarget allows calls to immediate address.
Remember the relocation model. NFC. This avoids passing a TargetMachine in a few places. llvm-svn: 270095
2016-05-20 02:49:29 +08:00
bool X86Subtarget::isLegalToCallImmediateAddr() const {
X86: Disable IsLegalToCallImmediateAddr for Win32 WinCOFF cannot form PC relative relocations to support absolute MCValues. We should reenable this once WinCOFF supports emission of IMAGE_REL_I386_REL32 relocations. This fixes PR19272. llvm-svn: 205058
2014-03-29 05:40:47 +08:00
// FIXME: I386 PE/COFF supports PC relative calls using IMAGE_REL_I386_REL32
// but WinCOFFObjectWriter::RecordRelocation cannot emit them. Once it does,
// the following check for Win32 should be removed.
if (In64BitMode || isTargetWin32())
Try again. Allow call to immediate address for ELF or when in static relocation mode. llvm-svn: 72160
2009-05-20 12:53:57 +08:00
return false;
Record a TargetMachine instead of a Reloc::Model. Addresses r270095's code review. llvm-svn: 270147
2016-05-20 06:07:57 +08:00
return isTargetELF() || TM.getRelocationModel() == Reloc::Static;
Try again. Allow call to immediate address for ELF or when in static relocation mode. llvm-svn: 72160
2009-05-20 12:53:57 +08:00
}
Remove resetSubtargetFeatures as it is unused. llvm-svn: 217071
2014-09-04 04:36:31 +08:00
void X86Subtarget::initSubtargetFeatures(StringRef CPU, StringRef FS) {
Revert r176166 because it broke one of the lit tests. llvm-svn: 176171
2013-02-27 13:56:20 +08:00
std::string CPUName = CPU;
X86: Remove TargetMachine CPU auto-detection. This logic is properly in the realm of whatever is creating the TargetMachine. This makes plain 'llc foo.ll' consistent across heterogenous machines. llvm-svn: 206094
2014-04-12 09:34:29 +08:00
if (CPUName.empty())
CPUName = "generic";
Really force on 64bit for 64-bit targets. Should fix remaining failures on unknown x86/non-x86 targets. llvm-svn: 134773
2011-07-09 07:43:01 +08:00
X86: Remove TargetMachine CPU auto-detection. This logic is properly in the realm of whatever is creating the TargetMachine. This makes plain 'llc foo.ll' consistent across heterogenous machines. llvm-svn: 206094
2014-04-12 09:34:29 +08:00
// Make sure 64-bit features are available in 64-bit mode. (But make sure
// SSE2 can be turned off explicitly.)
std::string FullFS = FS;
if (In64BitMode) {
if (!FullFS.empty())
FullFS = "+64bit,+sse2," + FullFS;
else
FullFS = "+64bit,+sse2";
Committing X86-64 support. llvm-svn: 30177
2006-09-08 14:48:29 +08:00
}
- Eliminate MCCodeEmitter's dependency on TargetMachine. It now uses MCInstrInfo and MCSubtargetInfo. - Added methods to update subtarget features (used when targets automatically detect subtarget features or switch modes). - Teach X86Subtarget to update MCSubtargetInfo features bits since the MCSubtargetInfo layer can be shared with other modules. - These fixes .code 16 / .code 32 support since mode switch is updated in MCSubtargetInfo so MC code emitter can do the right thing. llvm-svn: 134884
2011-07-11 11:57:24 +08:00
X86: Don't emit SAHF/LAHF for 64-bit targets unless explicitly supported These instructions are not supported by all CPUs in 64-bit mode. Emitting them causes Chromium to crash on start-up for users with such chips. (GCC puts these instructions behind -msahf on 64-bit for the same reason.) This patch adds FeatureLAHFSAHF, enables it by default for 32-bit targets and modern CPUs, and changes X86InstrInfo::copyPhysReg back to the lowering from before r244503 when the instructions are not available. Differential Revision: http://reviews.llvm.org/D15240 llvm-svn: 254793
2015-12-05 07:00:33 +08:00
// LAHF/SAHF are always supported in non-64-bit mode.
if (!In64BitMode) {
if (!FullFS.empty())
FullFS = "+sahf," + FullFS;
else
FullFS = "+sahf";
}
MC: Remove MCSubtargetInfo::InitCPUSched() Remove all calls to `MCSubtargetInfo::InitCPUSched()` and merge its body into the only relevant caller, `MCSubtargetInfo::InitMCProcessorInfo()`. We were only calling the former after explicitly calling the latter with the same CPU; it's confusing to have both methods exposed. Besides a minor (surely unmeasurable) speedup in ARM and X86 from avoiding running the logic twice, no functionality change. llvm-svn: 241956
2015-07-11 06:33:01 +08:00
// Parse features string and set the CPU.
X86: Remove TargetMachine CPU auto-detection. This logic is properly in the realm of whatever is creating the TargetMachine. This makes plain 'llc foo.ll' consistent across heterogenous machines. llvm-svn: 206094
2014-04-12 09:34:29 +08:00
ParseSubtargetFeatures(CPUName, FullFS);
make fast unaligned memory accesses implicit with SSE4.2 or SSE4a This is a follow-on from the discussion in http://reviews.llvm.org/D12154. This change allows memset/memcpy to use SSE or AVX memory accesses for any chip that has generally fast unaligned memory ops. A motivating use case for this change is a clang invocation that doesn't explicitly set the CPU, but does target a feature that we know only exists on a CPU that supports fast unaligned memops. For example: $ clang -O1 foo.c -mavx This resolves a difference in lowering noted in PR24449: https://llvm.org/bugs/show_bug.cgi?id=24449 Before this patch, we used different store types depending on whether the example can be lowered as a memset or not. Differential Revision: http://reviews.llvm.org/D12288 llvm-svn: 245950
2015-08-26 00:29:21 +08:00
// All CPUs that implement SSE4.2 or SSE4A support unaligned accesses of
// 16-bytes and under that are reasonably fast. These features were
// introduced with Intel's Nehalem/Silvermont and AMD's Family10h
// micro-architectures respectively.
if (hasSSE42() || hasSSE4A())
rename "slow-unaligned-mem-under-32" to slow-unaligned-mem-16" (NFCI) This is a follow-on suggested by: http://reviews.llvm.org/D12154 ( http://reviews.llvm.org/rL245729 ) http://reviews.llvm.org/D10662 ( http://reviews.llvm.org/rL245075 ) This makes the attribute name match most of the existing lowering logic and regression test expectations. But the current use of this attribute is inconsistent; see the FIXME comment for "allowsMisalignedMemoryAccesses()". That change will result in functional changes and should be coming soon. llvm-svn: 246585
2015-09-02 04:51:51 +08:00
IsUAMem16Slow = false;
make fast unaligned memory accesses implicit with SSE4.2 or SSE4a This is a follow-on from the discussion in http://reviews.llvm.org/D12154. This change allows memset/memcpy to use SSE or AVX memory accesses for any chip that has generally fast unaligned memory ops. A motivating use case for this change is a clang invocation that doesn't explicitly set the CPU, but does target a feature that we know only exists on a CPU that supports fast unaligned memops. For example: $ clang -O1 foo.c -mavx This resolves a difference in lowering noted in PR24449: https://llvm.org/bugs/show_bug.cgi?id=24449 Before this patch, we used different store types depending on whether the example can be lowered as a memset or not. Differential Revision: http://reviews.llvm.org/D12288 llvm-svn: 245950
2015-08-26 00:29:21 +08:00
Allow x86 subtargets to use the GenericModel defined in X86Schedule.td. This allows codegen passes to query properties like InstrItins->SchedModel->IssueWidth. It also ensure's that computeOperandLatency returns the X86 defaults for loads and "high latency ops". This should have no significant impact on existing schedulers because X86 defaults happen to be the same as global defaults. llvm-svn: 161370
2012-08-07 08:25:30 +08:00
InstrItins = getInstrItineraryForCPU(CPUName);
Instruction scheduling itinerary for Intel Atom. Adds an instruction itinerary to all x86 instructions, giving each a default latency of 1, using the InstrItinClass IIC_DEFAULT. Sets specific latencies for Atom for the instructions in files X86InstrCMovSetCC.td, X86InstrArithmetic.td, X86InstrControl.td, and X86InstrShiftRotate.td. The Atom latencies for the remainder of the x86 instructions will be set in subsequent patches. Adds a test to verify that the scheduler is working. Also changes the scheduling preference to "Hybrid" for i386 Atom, while leaving x86_64 as ILP. Patch by Preston Gurd! llvm-svn: 149558
2012-02-02 07:20:51 +08:00
- Eliminate MCCodeEmitter's dependency on TargetMachine. It now uses MCInstrInfo and MCSubtargetInfo. - Added methods to update subtarget features (used when targets automatically detect subtarget features or switch modes). - Teach X86Subtarget to update MCSubtargetInfo features bits since the MCSubtargetInfo layer can be shared with other modules. - These fixes .code 16 / .code 32 support since mode switch is updated in MCSubtargetInfo so MC code emitter can do the right thing. llvm-svn: 134884
2011-07-11 11:57:24 +08:00
// It's important to keep the MCSubtargetInfo feature bits in sync with
// target data structure which is shared with MC code emitter, etc.
if (In64BitMode)
ToggleFeature(X86::Mode64Bit);
[x86] Add basic support for .code16 This is not really expected to work right yet. Mostly because we will still emit the OpSize (0x66) prefix in all the wrong places, along with a number of other corner cases. Those will all be fixed in the subsequent commits. Patch from David Woodhouse. llvm-svn: 198584
2014-01-06 12:55:54 +08:00
else if (In32BitMode)
ToggleFeature(X86::Mode32Bit);
else if (In16BitMode)
ToggleFeature(X86::Mode16Bit);
else
llvm_unreachable("Not 16-bit, 32-bit or 64-bit mode!");
- Eliminate MCCodeEmitter's dependency on TargetMachine. It now uses MCInstrInfo and MCSubtargetInfo. - Added methods to update subtarget features (used when targets automatically detect subtarget features or switch modes). - Teach X86Subtarget to update MCSubtargetInfo features bits since the MCSubtargetInfo layer can be shared with other modules. - These fixes .code 16 / .code 32 support since mode switch is updated in MCSubtargetInfo so MC code emitter can do the right thing. llvm-svn: 134884
2011-07-11 11:57:24 +08:00
Change errs() to dbgs(). llvm-svn: 92648
2010-01-05 09:29:13 +08:00
DEBUG(dbgs() << "Subtarget features: SSELevel " << X86SSELevel
- s/DOUT/DEBUG(errs()/g - Tidy up some headers. llvm-svn: 77929
2009-08-03 08:11:34 +08:00
<< ", 3DNowLevel " << X863DNowLevel
<< ", 64bit " << HasX86_64 << "\n");
Add Mode64Bit feature and sink it down to MC layer. llvm-svn: 134641
2011-07-08 05:06:52 +08:00
assert((!In64BitMode || HasX86_64) &&
Change Feature64Bit to not imply FeatureSSE2. All x86-64 hardware has SSE2, however it's possible to disable SSE2, and the subtarget support code thinks that if 64-bit implies SSE2 and SSE2 is disabled then 64-bit should also be disabled. Instead, just mark all the 64-bit subtargets as explicitly supporting SSE2. Also, move the code that makes -march=x86-64 enable 64-bit support by default to only apply when there is no explicit subtarget. If you need to specify a subtarget and you want 64-bit code, you'll need to select a subtarget that supports 64-bit code. llvm-svn: 63575
2009-02-03 08:04:43 +08:00
"64-bit code requested on a subtarget that doesn't support it!");
Committing X86-64 support. llvm-svn: 30177
2006-09-08 14:48:29 +08:00
[X86] Extend some Linux special cases to cover kFreeBSD. Both Linux and kFreeBSD use glibc, so follow similiar code paths. Add isTargetGlibc to check for this, and use it instead of isTargetLinux in a few places. Fixes PR22248 for kFreeBSD. Differential Revision: http://reviews.llvm.org/D19104 llvm-svn: 268624
2016-05-05 19:35:51 +08:00
// Stack alignment is 16 bytes on Darwin, Linux, kFreeBSD and Solaris (both
Stack alignment is 16 bytes on FreeBSD/i386 too. llvm-svn: 126226
2011-02-23 01:30:05 +08:00
// 32 and 64 bit) and for all 64-bit targets.
Remove TargetOptions.h dependency from X86Subtarget. llvm-svn: 133726
2011-06-24 01:54:54 +08:00
if (StackAlignOverride)
stackAlignment = StackAlignOverride;
Switch FreeBSD/i386 back to 4byte stack alignment. This partially reverts r126226. llvm-svn: 167632
2012-11-10 04:10:44 +08:00
else if (isTargetDarwin() || isTargetLinux() || isTargetSolaris() ||
[X86] Extend some Linux special cases to cover kFreeBSD. Both Linux and kFreeBSD use glibc, so follow similiar code paths. Add isTargetGlibc to check for this, and use it instead of isTargetLinux in a few places. Fixes PR22248 for kFreeBSD. Differential Revision: http://reviews.llvm.org/D19104 llvm-svn: 268624
2016-05-05 19:35:51 +08:00
isTargetKFreeBSD() || In64BitMode)
Implement Subtarget support Implement the X86 Subtarget. This consolidates the checks for target triple, and setting options based on target triple into one place. This allows us to convert the asm printer and isel over from being littered with "forDarwin", "forCygwin", etc. into just having the appropriate flags for each subtarget feature controlling the code for that feature. This patch also implements indirect external and weak references in the X86 pattern isel, for darwin. Next up is to convert over the asm printers to use this new interface. llvm-svn: 22389
2005-07-12 09:41:54 +08:00
stackAlignment = 16;
[X86] Fix 80 column violation and remove trailing whitespace. NFC llvm-svn: 318611
2017-11-19 09:11:58 +08:00
[X86] Don't report gather is legal on Skylake CPUs when AVX2/AVX512 is disabled. Allow gather on SKX/CNL/ICL when AVX512 is disabled by using AVX2 instructions. Summary: This adds a new fast gather feature bit to cover all CPUs that support fast gather that we can use independent of whether the AVX512 feature is enabled. I'm only using this new bit to qualify AVX2 codegen. AVX512 is still implicitly assuming fast gather to keep tests working and to match the scatter behavior. Test command lines have been added for these two cases. Reviewers: magabari, delena, RKSimon, zvi Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40282 llvm-svn: 318983
2017-11-26 02:09:37 +08:00
// Some CPUs have more overhead for gather. The specified overhead is relative
// to the Load operation. "2" is the number provided by Intel architects. This
[X86] Fix 80 column violation and remove trailing whitespace. NFC llvm-svn: 318611
2017-11-19 09:11:58 +08:00
// parameter is used for cost estimation of Gather Op and comparison with
// other alternatives.
[X86] Don't report gather is legal on Skylake CPUs when AVX2/AVX512 is disabled. Allow gather on SKX/CNL/ICL when AVX512 is disabled by using AVX2 instructions. Summary: This adds a new fast gather feature bit to cover all CPUs that support fast gather that we can use independent of whether the AVX512 feature is enabled. I'm only using this new bit to qualify AVX2 codegen. AVX512 is still implicitly assuming fast gather to keep tests working and to match the scatter behavior. Test command lines have been added for these two cases. Reviewers: magabari, delena, RKSimon, zvi Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40282 llvm-svn: 318983
2017-11-26 02:09:37 +08:00
// TODO: Remove the explicit hasAVX512()?, That would mean we would only
// enable gather with a -march.
if (hasAVX512() || (hasAVX2() && hasFastGather()))
[X86] Adding X86 Processor Families Adding x86 Processor families to initialize several uArch properties (based on the family) This patch shows how gather cost can be initialized based on the proc. family Differential Revision: https://reviews.llvm.org/D35348 llvm-svn: 313132
2017-09-13 17:00:27 +08:00
GatherOverhead = 2;
if (hasAVX512())
ScatterOverhead = 2;
[X86] Add support for passing 'prefer-vector-width' function attribute into X86Subtarget and exposing via X86's getRegisterWidth TTI interface. This will cause the vectorizers to do some limiting of the vector widths they create. This is not a strict limit. There are reasons I know of that the loop vectorizer will generate larger vectors for. I've written this in such a way that the interface will only return a properly supported width(0/128/256/512) even if the attribute says something funny like 384 or 10. This has been split from D41895 with the remainder in a follow up commit. llvm-svn: 323015
2018-01-20 08:26:08 +08:00
// Consume the vector width attribute or apply any target specific limit.
if (PreferVectorWidthOverride)
PreferVectorWidth = PreferVectorWidthOverride;
else if (Prefer256Bit)
PreferVectorWidth = 256;
FastISel doesn't yet handle callee-pop functions. To support this, move IsCalleePop from X86ISelLowering to X86Subtarget. llvm-svn: 104866
2010-05-28 02:43:40 +08:00
}
Instruction scheduling itinerary for Intel Atom. Adds an instruction itinerary to all x86 instructions, giving each a default latency of 1, using the InstrItinClass IIC_DEFAULT. Sets specific latencies for Atom for the instructions in files X86InstrCMovSetCC.td, X86InstrArithmetic.td, X86InstrControl.td, and X86InstrShiftRotate.td. The Atom latencies for the remainder of the x86 instructions will be set in subsequent patches. Adds a test to verify that the scheduler is working. Also changes the scheduling preference to "Hybrid" for i386 Atom, while leaving x86_64 as ILP. Patch by Preston Gurd! llvm-svn: 149558
2012-02-02 07:20:51 +08:00
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
void X86Subtarget::initializeEnvironment() {
Move the MMX subtarget feature out of the SSE set of features and into its own variable. This is needed so that we can explicitly turn off MMX without turning off SSE and also so that we can diagnose feature set incompatibilities that involve MMX without SSE. Rationale: // sse3 __m128d test_mm_addsub_pd(__m128d A, __m128d B) { return _mm_addsub_pd(A, B); } // mmx void shift(__m64 a, __m64 b, int c) { _mm_slli_pi16(a, c); _mm_slli_pi32(a, c); _mm_slli_si64(a, c); _mm_srli_pi16(a, c); _mm_srli_pi32(a, c); _mm_srli_si64(a, c); _mm_srai_pi16(a, c); _mm_srai_pi32(a, c); } clang -msse3 -mno-mmx file.c -c For this code we should be able to explicitly turn off MMX without affecting the compilation of the SSE3 function and then diagnose and error on compiling the MMX function. This matches the existing gcc behavior and follows the spirit of the SSE/MMX separation in llvm where we can (and do) turn off MMX code generation except in the presence of intrinsics. Updated a couple of tests, but primarily tested with a couple of tests for turning on only mmx and only sse. This is paired with a patch to clang to take advantage of this behavior. llvm-svn: 249731
2015-10-09 04:10:06 +08:00
X86SSELevel = NoSSE;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
X863DNowLevel = NoThreeDNow;
[X86] Introduction of FeatureX87. Add FeatureX87 in X86 backend to be able to define CPUs which doesn't have x87. Differential Revision: http://reviews.llvm.org/D13979 llvm-svn: 264148
2016-03-23 19:13:54 +08:00
HasX87 = false;
[X86] Move HasNOPL to a subtarget feature bit. Plumb MCSubtargetInfo through the MCAsmBackend constructor After D41349, we can no get a MCSubtargetInfo into the MCAsmBackend constructor. This allows us to get NOPL from a subtarget feature rather than a CPU name blacklist. Differential Revision: https://reviews.llvm.org/D41721 llvm-svn: 322227
2018-01-11 06:07:16 +08:00
HasNOPL = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasCMov = false;
HasX86_64 = false;
HasPOPCNT = false;
HasSSE4A = false;
HasAES = false;
[x86][icelake]VAES introduction an icelake promotion of AES Differential Revision: https://reviews.llvm.org/D40078 llvm-svn: 318740
2017-11-21 17:11:41 +08:00
HasVAES = false;
[X86] Add fxsr feature flag for fxsave/fxrestore instructions. llvm-svn: 250497
2015-10-16 14:03:09 +08:00
HasFXSR = false;
[X86] Add XSAVE intrinsic family Add intrinsics for the XSAVE instructions (XSAVE/XSAVE64/XRSTOR/XRSTOR64) XSAVEOPT instructions (XSAVEOPT/XSAVEOPT64) XSAVEC instructions (XSAVEC/XSAVEC64) XSAVES instructions (XSAVES/XSAVES64/XRSTORS/XRSTORS64) Differential Revision: http://reviews.llvm.org/D13012 llvm-svn: 250029
2015-10-12 19:47:46 +08:00
HasXSAVE = false;
HasXSAVEOPT = false;
HasXSAVEC = false;
HasXSAVES = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasPCLMUL = false;
[x86][icelake]vpclmulqdq introduction an icelake promotion of pclmulqdq Differential Revision: https://reviews.llvm.org/D40101 llvm-svn: 318741
2017-11-21 17:30:33 +08:00
HasVPCLMULQDQ = false;
[x86][icelake]GFNI galois field arithmetic (GF(2^8)) insns: gf2p8affineinvqb gf2p8affineqb gf2p8mulb Differential Revision: https://reviews.llvm.org/D40373 llvm-svn: 318993
2017-11-26 17:36:41 +08:00
HasGFNI = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasFMA = false;
HasFMA4 = false;
HasXOP = false;
Adding a feature flag to the llvm backend for x86 TBM instruction set. Adding TBM feature to bdver2 processor; piledriver supports this instruction set according to the following document: http://developer.amd.com/wordpress/media/2012/10/New-Bulldozer-and-Piledriver-Instructions.pdf Phabricator code review is located here: http://llvm-reviews.chandlerc.com/D1692 llvm-svn: 191324
2013-09-25 02:21:52 +08:00
HasTBM = false;
[X86][LWP] Add llvm support for LWP instructions (reapplied). This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4). Reapplied - this time without changing line endings of existing files. Differential Revision: https://reviews.llvm.org/D32769 llvm-svn: 302041
2017-05-03 23:51:39 +08:00
HasLWP = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasMOVBE = false;
HasRDRAND = false;
HasF16C = false;
HasFSGSBase = false;
HasLZCNT = false;
HasBMI = false;
HasBMI2 = false;
[AVX512] adding AVXVBMI feature flag The feature flag is for VPERMB,VPERMI2B,VPERMT2B and VPMULTISHIFTQB instructions. More about the instruction can be found in: hattps://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf Differential Revision: http://reviews.llvm.org/D16190 llvm-svn: 258012
2016-01-17 21:42:12 +08:00
HasVBMI = false;
[x86][icelake]vbmi2 introducing vbmi2, consisting of vpcompress{b,w} vpexpand{b,w} vpsh{l,r}d{w,d,q} vpsh{l,r}dv{w,d,q} Differential Revision: https://reviews.llvm.org/D40206 llvm-svn: 318745
2017-11-21 17:48:44 +08:00
HasVBMI2 = false;
Added Skylake client to X86 targets and features Changes in X86.td: I set features of Intel processors in incremental form: IVB = SNB + X HSW = IVB + X .. I added Skylake client processor and defined it's features FeatureADX was missing on KNL Added some new features to appropriate processors SMAP, IFMA, PREFETCHWT1, VMFUNC and others Differential Revision: http://reviews.llvm.org/D16357 llvm-svn: 258659
2016-01-24 18:41:28 +08:00
HasIFMA = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasRTM = false;
Added encoding prefixes for KNL instructions (EVEX). Added 512-bit operands printing. Added instruction formats for KNL instructions. llvm-svn: 187324
2013-07-28 16:28:38 +08:00
HasERI = false;
HasCDI = false;
Fix formatting. No functional change. llvm-svn: 188746
2013-08-20 13:23:59 +08:00
HasPFI = false;
[SKX] Enabling SKX target and AVX512BW, AVX512DQ, AVX512VL features. Enabling HasAVX512{DQ,BW,VL} predicates. Adding VK2, VK4, VK32, VK64 masked register classes. Adding new types (v64i8, v32i16) to VR512. Extending calling conventions for new types (v64i8, v32i16) Patch by Zinovy Nis <zinovy.y.nis@intel.com> Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 213545
2014-07-21 22:54:21 +08:00
HasDQI = false;
[X86] Adding vpopcntd and vpopcntq instructions AVX512_VPOPCNTDQ is a new feature set that was published by Intel. The patch represents the LLVM side of the addition of two new intrinsic based instructions (vpopcntd and vpopcntq). Differential Revision: https://reviews.llvm.org/D33169 llvm-svn: 303858
2017-05-25 21:45:23 +08:00
HasVPOPCNTDQ = false;
[SKX] Enabling SKX target and AVX512BW, AVX512DQ, AVX512VL features. Enabling HasAVX512{DQ,BW,VL} predicates. Adding VK2, VK4, VK32, VK64 masked register classes. Adding new types (v64i8, v32i16) to VR512. Extending calling conventions for new types (v64i8, v32i16) Patch by Zinovy Nis <zinovy.y.nis@intel.com> Reviewed by Elena Demikhovsky <elena.demikhovsky@intel.com> llvm-svn: 213545
2014-07-21 22:54:21 +08:00
HasBWI = false;
HasVLX = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasADX = false;
[x86] adding PKU feature flag the feature flag is essential for RDPKRU and WRPKRU instruction more about the instruction can be found in the SDM rev 56, vol 2 from http://www.intel.com/sdm Differential Revision: http://reviews.llvm.org/D15491 llvm-svn: 255644
2015-12-15 21:35:29 +08:00
HasPKU = false;
[x86][icelake]VNNI Introducing Vector Neural Network Instructions, consisting of: vpdpbusd{s} vpdpwssd{s} Differential Revision: https://reviews.llvm.org/D40208 llvm-svn: 318746
2017-11-21 18:04:28 +08:00
HasVNNI = false;
[x86][icelake]BITALG vpopcnt{b,w} Differential Revision: https://reviews.llvm.org/D40213 llvm-svn: 318748
2017-11-21 18:32:42 +08:00
HasBITALG = false;
Partial support for Intel SHA Extensions (sha1rnds4) Add basic assembly/disassembly support for the first Intel SHA instruction 'sha1rnds4'. Also includes feature flag, and test cases. Support for the remaining instructions will follow in a separate patch. llvm-svn: 190611
2013-09-12 23:51:31 +08:00
HasSHA = false;
[X86] Add missing initialization for the HasPREFETCHWT1 subtarget variable. llvm-svn: 321340
2017-12-22 11:53:14 +08:00
HasPREFETCHWT1 = false;
Add PREFETCHW codegen support - Add 'PRFCHW' feature defined in AVX2 ISA extension llvm-svn: 178040
2013-03-27 01:47:11 +08:00
HasPRFCHW = false;
Add support of RDSEED defined in AVX2 extension llvm-svn: 178314
2013-03-29 07:41:26 +08:00
HasRDSEED = false;
X86: Don't emit SAHF/LAHF for 64-bit targets unless explicitly supported These instructions are not supported by all CPUs in 64-bit mode. Emitting them causes Chromium to crash on start-up for users with such chips. (GCC puts these instructions behind -msahf on 64-bit for the same reason.) This patch adds FeatureLAHFSAHF, enables it by default for 32-bit targets and modern CPUs, and changes X86InstrInfo::copyPhysReg back to the lowering from before r244503 when the instructions are not available. Differential Revision: http://reviews.llvm.org/D15240 llvm-svn: 254793
2015-12-05 07:00:33 +08:00
HasLAHFSAHF = false;
Add new flag and intrinsic support for MWAITX and MONITORX instructions Summary: MONITORX/MWAITX instructions provide similar capability to the MONITOR/MWAIT pair while adding a timer function, such that another termination of the MWAITX instruction occurs when the timer expires. The presence of the MONITORX and MWAITX instructions is indicated by CPUID 8000_0001, ECX, bit 29. The MONITORX and MWAITX instructions are intercepted by the same bits that intercept MONITOR and MWAIT. MONITORX instruction establishes a range to be monitored. MWAITX instruction causes the processor to stop instruction execution and enter an implementation-dependent optimized state until occurrence of a class of events. Opcode of MONITORX instruction is "0F 01 FA". Opcode of MWAITX instruction is "0F 01 FB". These opcode information is used in adding tests for the disassembler. These instructions are enabled for AMD's bdver4 architecture. Patch by Ganesh Gopalasubramanian! Reviewers: echristo, craig.topper, RKSimon Subscribers: RKSimon, joker.eph, llvm-commits Differential Revision: http://reviews.llvm.org/D19795 llvm-svn: 269911
2016-05-18 19:59:12 +08:00
HasMWAITX = false;
[X86] Clzero intrinsic and its addition under znver1 This patch does the following. 1. Adds an Intrinsic int_x86_clzero which works with __builtin_ia32_clzero 2. Identifies clzero feature using cpuid info. (Function:8000_0008, Checks if EBX[0]=1) 3. Adds the clzero feature under znver1 architecture. 4. The custom inserter is added in Lowering. 5. A testcase is added to check the intrinsic. 6. The clzero instruction is added to assembler test. Patch by Ganesh Gopalasubramanian with a couple formatting tweaks, a disassembler test, and using update_llc_test.py from me. Differential revision: https://reviews.llvm.org/D29385 llvm-svn: 294558
2017-02-09 12:27:34 +08:00
HasCLZERO = false;
X86: Added MPX feature and bound registers. Intel® Memory Protection Extensions (Intel® MPX) is a new feature in Skylake. It is a part of KNL and SKX sets. It is also a part of Skylake client. I added definition of %bnd0 - %bnd3 registers, each register is a pair of 64-bit integers. llvm-svn: 238916
2015-06-03 18:30:57 +08:00
HasMPX = false;
Control-Flow Enforcement Technology - Shadow Stack support (LLVM side) Shadow stack solution introduces a new stack for return addresses only. The HW has a Shadow Stack Pointer (SSP) that points to the next return address. If we return to a different address, an exception is triggered. The shadow stack is managed using a series of intrinsics that are introduced in this patch as well as the new register (SSP). The intrinsics are mapped to new instruction set that implements CET mechanism. The patch also includes initial infrastructure support for IBT. For more information, please see the following: https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf Differential Revision: https://reviews.llvm.org/D40223 Change-Id: I4daa1f27e88176be79a4ac3b4cd26a459e88fed4 llvm-svn: 318996
2017-11-26 21:02:45 +08:00
HasSHSTK = false;
HasIBT = false;
X86: initialize a few subtarget variables. Otherwise an indeterminate value gets read, causing a bunch of UBSan failures. llvm-svn: 301819
2017-05-02 01:50:15 +08:00
HasSGX = false;
HasCLFLUSHOPT = false;
HasCLWB = false;
[X86] Add intrinsic support for the RDPID instruction This adds a new instrinsic to support the rdpid instruction. The implementation is a bit weird because the intrinsic is defined as always returning 32-bits, but the assembler support thinks the instruction produces a 64-bit register in 64-bit mode. But really it zeros the upper 32 bits. So I had to add separate patterns where 64-bit mode uses an extract_subreg. Differential Revision: https://reviews.llvm.org/D42205 llvm-svn: 322910
2018-01-19 07:52:31 +08:00
HasRDPID = false;
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre.. Summary: First, we need to explain the core of the vulnerability. Note that this is a very incomplete description, please see the Project Zero blog post for details: https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html The basis for branch target injection is to direct speculative execution of the processor to some "gadget" of executable code by poisoning the prediction of indirect branches with the address of that gadget. The gadget in turn contains an operation that provides a side channel for reading data. Most commonly, this will look like a load of secret data followed by a branch on the loaded value and then a load of some predictable cache line. The attacker then uses timing of the processors cache to determine which direction the branch took *in the speculative execution*, and in turn what one bit of the loaded value was. Due to the nature of these timing side channels and the branch predictor on Intel processors, this allows an attacker to leak data only accessible to a privileged domain (like the kernel) back into an unprivileged domain. The goal is simple: avoid generating code which contains an indirect branch that could have its prediction poisoned by an attacker. In many cases, the compiler can simply use directed conditional branches and a small search tree. LLVM already has support for lowering switches in this way and the first step of this patch is to disable jump-table lowering of switches and introduce a pass to rewrite explicit indirectbr sequences into a switch over integers. However, there is no fully general alternative to indirect calls. We introduce a new construct we call a "retpoline" to implement indirect calls in a non-speculatable way. It can be thought of loosely as a trampoline for indirect calls which uses the RET instruction on x86. Further, we arrange for a specific call->ret sequence which ensures the processor predicts the return to go to a controlled, known location. The retpoline then "smashes" the return address pushed onto the stack by the call with the desired target of the original indirect call. The result is a predicted return to the next instruction after a call (which can be used to trap speculative execution within an infinite loop) and an actual indirect branch to an arbitrary address. On 64-bit x86 ABIs, this is especially easily done in the compiler by using a guaranteed scratch register to pass the target into this device. For 32-bit ABIs there isn't a guaranteed scratch register and so several different retpoline variants are introduced to use a scratch register if one is available in the calling convention and to otherwise use direct stack push/pop sequences to pass the target address. This "retpoline" mitigation is fully described in the following blog post: https://support.google.com/faqs/answer/7625886 We also support a target feature that disables emission of the retpoline thunk by the compiler to allow for custom thunks if users want them. These are particularly useful in environments like kernels that routinely do hot-patching on boot and want to hot-patch their thunk to different code sequences. They can write this custom thunk and use `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this case, on x86-64 thu thunk names must be: ``` __llvm_external_retpoline_r11 ``` or on 32-bit: ``` __llvm_external_retpoline_eax __llvm_external_retpoline_ecx __llvm_external_retpoline_edx __llvm_external_retpoline_push ``` And the target of the retpoline is passed in the named register, or in the case of the `push` suffix on the top of the stack via a `pushl` instruction. There is one other important source of indirect branches in x86 ELF binaries: the PLT. These patches also include support for LLD to generate PLT entries that perform a retpoline-style indirection. The only other indirect branches remaining that we are aware of are from precompiled runtimes (such as crt0.o and similar). The ones we have found are not really attackable, and so we have not focused on them here, but eventually these runtimes should also be replicated for retpoline-ed configurations for completeness. For kernels or other freestanding or fully static executables, the compiler switch `-mretpoline` is sufficient to fully mitigate this particular attack. For dynamic executables, you must compile *all* libraries with `-mretpoline` and additionally link the dynamic executable and all shared libraries with LLD and pass `-z retpolineplt` (or use similar functionality from some other linker). We strongly recommend also using `-z now` as non-lazy binding allows the retpoline-mitigated PLT to be substantially smaller. When manually apply similar transformations to `-mretpoline` to the Linux kernel we observed very small performance hits to applications running typical workloads, and relatively minor hits (approximately 2%) even for extremely syscall-heavy applications. This is largely due to the small number of indirect branches that occur in performance sensitive paths of the kernel. When using these patches on statically linked applications, especially C++ applications, you should expect to see a much more dramatic performance hit. For microbenchmarks that are switch, indirect-, or virtual-call heavy we have seen overheads ranging from 10% to 50%. However, real-world workloads exhibit substantially lower performance impact. Notably, techniques such as PGO and ThinLTO dramatically reduce the impact of hot indirect calls (by speculatively promoting them to direct calls) and allow optimized search trees to be used to lower switches. If you need to deploy these techniques in C++ applications, we *strongly* recommend that you ensure all hot call targets are statically linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well tuned servers using all of these techniques saw 5% - 10% overhead from the use of retpoline. We will add detailed documentation covering these components in subsequent patches, but wanted to make the core functionality available as soon as possible. Happy for more code review, but we'd really like to get these patches landed and backported ASAP for obvious reasons. We're planning to backport this to both 6.0 and 5.0 release streams and get a 5.0 release with just this cherry picked ASAP for distros and vendors. This patch is the work of a number of people over the past month: Eric, Reid, Rui, and myself. I'm mailing it out as a single commit due to the time sensitive nature of landing this and the need to backport it. Huge thanks to everyone who helped out here, and everyone at Intel who helped out in discussions about how to craft this. Also, credit goes to Paul Turner (at Google, but not an LLVM contributor) for much of the underlying retpoline design. Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits Differential Revision: https://reviews.llvm.org/D41723 llvm-svn: 323155
2018-01-23 06:05:25 +08:00
UseRetpoline = false;
UseRetpolineExternalThunk = false;
[X86] Prefer reduced width multiplication over pmulld on Silvermont Summary: Prefer expansions such as: pmullw,pmulhw,unpacklwd,unpackhwd over pmulld. On Silvermont [source: Optimization Reference Manual]: PMULLD has a throughput of 1/11 [instruction/cycles]. PMULHUW/PMULHW/PMULLW have a throughput of 1/2 [instruction/cycles]. Fixes pr31202. Analysis of this issue was done by Fahana Aleen. Reviewers: wmi, delena, mkuper Subscribers: RKSimon, llvm-commits Differential Revision: https://reviews.llvm.org/D27203 llvm-svn: 288844
2016-12-07 03:35:20 +08:00
IsPMULLDSlow = false;
SHLD/SHRD are VectorPath (microcode) instructions known to have poor latency on certain architectures. While generating SHLD/SHRD instructions is acceptable when optimizing for size, optimizing for speed on these platforms should be implemented using alternative sequences of instructions composed of add, adc, shr, shl, or and lea which are directPath instructions. These alternative instructions not only have a lower latency but they also increase the decode bandwidth by allowing simultaneous decoding of a third directPath instruction. AMD's processors family K7, K8, K10, K12, K15 and K16 are known to have SHLD/SHRD instructions with very poor latency. Optimization guides for these processors recommend using an alternative sequence of instructions. For these AMD's processors, I disabled folding (or (x << c) | (y >> (64 - c))) when we are not optimizing for size. It might be beneficial to disable this folding for some of the Intel's processors. However, since I couldn't find specific recommendations regarding using SHLD/SHRD instructions on Intel's processors, I haven't disabled this peephole for Intel. llvm-svn: 195383
2013-11-22 07:21:26 +08:00
IsSHLDSlow = false;
rename "slow-unaligned-mem-under-32" to slow-unaligned-mem-16" (NFCI) This is a follow-on suggested by: http://reviews.llvm.org/D12154 ( http://reviews.llvm.org/rL245729 ) http://reviews.llvm.org/D10662 ( http://reviews.llvm.org/rL245075 ) This makes the attribute name match most of the existing lowering logic and regression test expectations. But the current use of this attribute is inconsistent; see the FIXME comment for "allowsMisalignedMemoryAccesses()". That change will result in functional changes and should be coming soon. llvm-svn: 246585
2015-09-02 04:51:51 +08:00
IsUAMem16Slow = false;
Add a feature flag for slow 32-byte unaligned memory accesses [x86]. This patch adds a feature flag to avoid unaligned 32-byte load/store AVX codegen for Sandy Bridge and Ivy Bridge. There is no functionality change intended for those chips. Previously, the absence of AVX2 was being used as a proxy to detect this feature. But that hindered codegen for AVX-enabled AMD chips such as btver2 that do not have the 32-byte unaligned access slowdown. Performance measurements are included in PR21541 ( http://llvm.org/bugs/show_bug.cgi?id=21541 ). Differential Revision: http://reviews.llvm.org/D6355 llvm-svn: 222544
2014-11-22 01:40:04 +08:00
IsUAMem32Slow = false;
Fix program crashes due to alignment exceptions generated for SSE memop instructions (PR22371). r224330 introduced a bug by misinterpreting the "FeatureVectorUAMem" bit. The commit log says that change did not affect anything, but that's not correct. That change allowed SSE instructions to have unaligned mem operands folded into math ops, and that's not allowed in the default specification for any SSE variant. The bug is exposed when compiling for an AVX-capable CPU that had this feature flag but without enabling AVX codegen. Another mistake in r224330 was not adding the feature flag to all AVX CPUs; the AMD chips were excluded. This is part of the fix for PR22371 ( http://llvm.org/bugs/show_bug.cgi?id=22371 ). This feature bit is SSE-specific, so I've renamed it to "FeatureSSEUnalignedMem". Changed the existing test case for the feature bit to reflect the new name and renamed the test file itself to better reflect the feature. Added runs to fold-vex.ll to check for the failing codegen. Note that the feature bit is not set by default on any CPU because it may require a configuration register setting to enable the enhanced unaligned behavior. llvm-svn: 227983
2015-02-04 01:13:04 +08:00
HasSSEUnalignedMem = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
HasCmpxchg16b = false;
UseLeaForSP = false;
Break false dependencies for POPCNT, LZCNT, TZCNT Add POPCNT, LZCNT, TZCNT to the list of instructions that have false dependency. Add a test to make sure BreakFalseDeps breaks the dependencies for these instructions. Update affected tests. This fixes bugzilla https://bugs.llvm.org/show_bug.cgi?id=33869 This is the final of multiple patches that fix this bugzilla. Most of the patches are intended at refactoring the existent code. Reviews of the refactoring done to enable this change: https://reviews.llvm.org/D40330 https://reviews.llvm.org/D40331 https://reviews.llvm.org/D40332 https://reviews.llvm.org/D40333 Differential Revision: https://reviews.llvm.org/D40334 Change-Id: If95cbf1a3f5c7dccff8f1b22ecb397542147303d llvm-svn: 323096
2018-01-22 18:07:01 +08:00
HasPOPCNTFalseDeps = false;
HasLZCNTFalseDeps = false;
[X86] Fix uninitialized variable sanitizer warning from rL321074 llvm-svn: 321076
2017-12-19 22:34:35 +08:00
HasFastVariableShuffle = false;
[X86] Generate VZEROUPPER for Skylake-avx512. VZEROUPPER should not be issued on Knights Landing (KNL), but on Skylake-avx512 it should be. Differential Revision: https://reviews.llvm.org/D29874 llvm-svn: 296859
2017-03-03 17:03:24 +08:00
HasFastPartialYMMorZMMWrite = false;
[X86] Emit 11-byte or 15-byte NOPs on recent AMD targets, else default to 10-byte NOPs (PR22965) We currently emit up to 15-byte NOPs on all targets (apart from Silvermont), which stalls performance on some targets with decoders that struggle with 2 or 3 more '66' prefixes. This patch flags recent AMD targets (btver1/znver1) to still emit 15-byte NOPs and bdver* targets to emit 11-byte NOPs. All other targets now emit 10-byte NOPs apart from SilverMont CPUs which still emit 7-byte NOPS. Differential Revision: https://reviews.llvm.org/D42616 llvm-svn: 323693
2018-01-30 05:24:31 +08:00
HasFast11ByteNOP = false;
HasFast15ByteNOP = false;
[X86] Don't report gather is legal on Skylake CPUs when AVX2/AVX512 is disabled. Allow gather on SKX/CNL/ICL when AVX512 is disabled by using AVX2 instructions. Summary: This adds a new fast gather feature bit to cover all CPUs that support fast gather that we can use independent of whether the AVX512 feature is enabled. I'm only using this new bit to qualify AVX2 codegen. AVX512 is still implicitly assuming fast gather to keep tests working and to match the scatter behavior. Test command lines have been added for these two cases. Reviewers: magabari, delena, RKSimon, zvi Reviewed By: RKSimon Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D40282 llvm-svn: 318983
2017-11-26 02:09:37 +08:00
HasFastGather = false;
[X86] Heuristic to selectively build Newton-Raphson SQRT estimation On modern Intel processors hardware SQRT in many cases is faster than RSQRT followed by Newton-Raphson refinement. The patch introduces a simple heuristic to choose between hardware SQRT instruction and Newton-Raphson software estimation. The patch treats scalars and vectors differently. The heuristic is that for scalars the compiler should optimize for latency while for vectors it should optimize for throughput. It is based on the assumption that throughput bound code is likely to be vectorized. Basically, the patch disables scalar NR for big cores and disables NR completely for Skylake. Firstly, scalar SQRT has shorter latency than NR code in big cores. Secondly, vector SQRT has been greatly improved in Skylake and has better throughput compared to NR. Differential Revision: https://reviews.llvm.org/D21379 llvm-svn: 277725
2016-08-04 20:47:28 +08:00
HasFastScalarFSQRT = false;
HasFastVectorFSQRT = false;
[X86] Take advantage of the lzcnt instruction on btver2 architectures when ORing comparisons to zero. This change adds transformations such as: zext(or(setcc(eq, (cmp x, 0)), setcc(eq, (cmp y, 0)))) To: srl(or(ctlz(x), ctlz(y)), log2(bitsize(x)) This optimisation is beneficial on Jaguar architecture only, where lzcnt has a good reciprocal throughput. Other architectures such as Intel's Haswell/Broadwell or AMD's Bulldozer/PileDriver do not benefit from it. For this reason the change also adds a "HasFastLZCNT" feature which gets enabled for Jaguar. Differential Revision: https://reviews.llvm.org/D23446 llvm-svn: 284248
2016-10-15 00:41:38 +08:00
HasFastLZCNT = false;
[X86] Use SHLD with both inputs from the same register to implement rotate on Sandy Bridge and later Intel CPUs Summary: Sandy Bridge and later CPUs have better throughput using a SHLD to implement rotate versus the normal rotate instructions. Additionally it saves one uop and avoids a partial flag update dependency. This patch implements this change on any Sandy Bridge or later processor without BMI2 instructions. With BMI2 we will use RORX as we currently do. Reviewers: zvi Reviewed By: zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D30181 llvm-svn: 295697
2017-02-21 14:39:13 +08:00
HasFastSHLDRotate = false;
[X86] Provide a separate feature bit for macro fusion support instead of basing it on the AVX flag Summary: Currently we determine if macro fusion is supported based on the AVX flag as a proxy for the processor being Sandy Bridge". This is really strange as now AMD supports AVX. It also means if user explicitly disables AVX we disable macro fusion. This patch adds an explicit macro fusion feature. I've also enabled for the generic 64-bit CPU (which doesn't have AVX) This is probably another candidate for being in the MI layer, but for now I at least wanted to correct the overloading of the AVX feature. Reviewers: spatel, chandlerc, RKSimon, zvi Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37280 llvm-svn: 312097
2017-08-30 12:34:48 +08:00
HasMacroFusion = false;
Rename FastString flag. llvm-svn: 300959
2017-04-21 17:20:50 +08:00
HasERMSB = false;
[X86] For Silvermont CPU use 16-bit division instead of 64-bit for small positive numbers Differential Revision: http://reviews.llvm.org/D5938 llvm-svn: 222521
2014-11-21 19:19:34 +08:00
HasSlowDivide32 = false;
HasSlowDivide64 = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
PadShortFunctions = false;
Mark Knights Landing as having slow two memory operand instructions Summary: Knights Landing, because it is Atom derived, has slow two memory operand instructions. Mark the Knights Landing CPU model accordingly. Patch by David Zarzycki. Reviewers: craig.topper Reviewed By: craig.topper Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D37224 llvm-svn: 311979
2017-08-29 13:14:27 +08:00
SlowTwoMemOps = false;
This patch adds the X86FixupLEAs pass, which will reduce instruction latency for certain models of the Intel Atom family, by converting instructions into their equivalent LEA instructions, when it is both useful and possible to do so. llvm-svn: 180573
2013-04-26 04:29:37 +08:00
LEAUsesAG = false;
[X86] Tune LEA usage for Silvermont According to Intel Software Optimization Manual on Silvermont in some cases LEA is better to be replaced with ADD instructions: "The rule of thumb for ADDs and LEAs is that it is justified to use LEA with a valid index and/or displacement for non-destructive destination purposes (especially useful for stack offset cases), or to use a SCALE. Otherwise, ADD(s) are preferable." Differential Revision: http://reviews.llvm.org/D3826 llvm-svn: 209198
2014-05-20 16:55:50 +08:00
SlowLEA = false;
[X86] Replace slow LEA instructions in X86 According to Intel's Optimization Reference Manual for SNB+: " For LEA instructions with three source operands and some specific situations, instruction latency has increased to 3 cycles, and must dispatch via port 1: - LEA that has all three source operands: base, index, and offset - LEA that uses base and index registers where the base is EBP, RBP,or R13 - LEA that uses RIP relative addressing mode - LEA that uses 16-bit addressing mode " This patch currently handles the first 2 cases only. Differential Revision: https://reviews.llvm.org/D32277 llvm-svn: 303333
2017-05-18 16:11:50 +08:00
Slow3OpsLEA = false;
[X86] Use ADD/SUB instead of INC/DEC for Silvermont According to Intel Software Optimization Manual on Silvermont INC or DEC instructions require an additional uop to merge the flags. As a result, a branch instruction depending on an INC or a DEC instruction incurs a 1 cycle penalty. Differential Revision: http://reviews.llvm.org/D3990 llvm-svn: 210466
2014-06-09 19:40:41 +08:00
SlowIncDec = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
stackAlignment = 4;
// FIXME: this is a known good value for Yonah. How about others?
MaxInlineSizeThreshold = 128;
Migrate existing backends that care about software floating point to use the information in the module rather than TargetOptions. We've had and clang has used the use-soft-float attribute for some time now so have the backends set a subtarget feature based on a particular function now that subtargets are created based on functions and function attributes. For the one middle end soft float check go ahead and create an overloadable TargetLowering::useSoftFloat function that just checks the TargetSubtargetInfo in all cases. Also remove the command line option that hard codes whether or not soft-float is set by using the attribute for all of the target specific test cases - for the generic just go ahead and add the attribute in the one case that showed up. llvm-svn: 237079
2015-05-12 09:26:05 +08:00
UseSoftFloat = false;
[X86] Adding X86 Processor Families Adding x86 Processor families to initialize several uArch properties (based on the family) This patch shows how gather cost can be initialized based on the proc. family Differential Revision: https://reviews.llvm.org/D35348 llvm-svn: 313132
2017-09-13 17:00:27 +08:00
X86ProcFamily = Others;
GatherOverhead = 1024;
ScatterOverhead = 1024;
[X86] Add support for passing 'prefer-vector-width' function attribute into X86Subtarget and exposing via X86's getRegisterWidth TTI interface. This will cause the vectorizers to do some limiting of the vector widths they create. This is not a strict limit. There are reasons I know of that the loop vectorizer will generate larger vectors for. I've written this in such a way that the interface will only return a properly supported width(0/128/256/512) even if the attribute says something funny like 384 or 10. This has been split from D41895 with the remainder in a follow up commit. llvm-svn: 323015
2018-01-20 08:26:08 +08:00
PreferVectorWidth = UINT32_MAX;
Prefer256Bit = false;
Reinitialize the ivars in the subtarget so that they can be reset with the new features. llvm-svn: 175336
2013-02-16 09:36:26 +08:00
}
Move to a private function to initialize the subtarget dependencies so that we can use initializer lists for the X86Subtarget. llvm-svn: 210614
2014-06-11 08:25:19 +08:00
X86Subtarget &X86Subtarget::initializeSubtargetDependencies(StringRef CPU,
StringRef FS) {
initializeEnvironment();
Remove resetSubtargetFeatures as it is unused. llvm-svn: 217071
2014-09-04 04:36:31 +08:00
initSubtargetFeatures(CPU, FS);
Move to a private function to initialize the subtarget dependencies so that we can use initializer lists for the X86Subtarget. llvm-svn: 210614
2014-06-11 08:25:19 +08:00
return *this;
}
[X86] Reduce memory allocations in X86TargetMachine::getSubtargetImpl We performed a number of memory allocations each time getTTI was called, remove them by using SmallString. No functionality change intended. llvm-svn: 270246
2016-05-21 02:16:06 +08:00
X86Subtarget::X86Subtarget(const Triple &TT, StringRef CPU, StringRef FS,
const X86TargetMachine &TM,
[X86] Add support for passing 'prefer-vector-width' function attribute into X86Subtarget and exposing via X86's getRegisterWidth TTI interface. This will cause the vectorizers to do some limiting of the vector widths they create. This is not a strict limit. There are reasons I know of that the loop vectorizer will generate larger vectors for. I've written this in such a way that the interface will only return a properly supported width(0/128/256/512) even if the attribute says something funny like 384 or 10. This has been split from D41895 with the remainder in a follow up commit. llvm-svn: 323015
2018-01-20 08:26:08 +08:00
unsigned StackAlignOverride,
[X86] Don't make 512-bit vectors legal when preferred vector width is 256 bits and 512 bits aren't required This patch adds a new function attribute "required-vector-width" that can be set by the frontend to indicate the maximum vector width present in the original source code. The idea is that this would be set based on ABI requirements, intrinsics or explicit vector types being used, maybe simd pragmas, etc. The backend will then use this information to determine if its save to make 512-bit vectors illegal when the preference is for 256-bit vectors. For code that has no vectors in it originally and only get vectors through the loop and slp vectorizers this allows us to generate code largely similar to our AVX2 only output while still enabling AVX512 features like mask registers and gather/scatter. The loop vectorizer doesn't always obey TTI and will create oversized vectors with the expectation the backend will legalize it. In order to avoid changing the vectorizer and potentially harm our AVX2 codegen this patch tries to make the legalizer behavior similar. This is restricted to CPUs that support AVX512F and AVX512VL so that we have good fallback options to use 128 and 256-bit vectors and still get masking. I've qualified every place I could find in X86ISelLowering.cpp and added tests cases for many of them with 2 different values for the attribute to see the codegen differences. We still need to do frontend work for the attribute and teach the inliner how to merge it, etc. But this gets the codegen layer ready for it. Differential Revision: https://reviews.llvm.org/D42724 llvm-svn: 324834
2018-02-11 16:06:27 +08:00
unsigned PreferVectorWidthOverride,
unsigned RequiredVectorWidth)
Revert r247692: Replace Triple with a new TargetTuple in MCTargetDesc/* and related. NFC. Eric has replied and has demanded the patch be reverted. llvm-svn: 247702
2015-09-16 00:17:27 +08:00
: X86GenSubtargetInfo(TT, CPU, FS), X86ProcFamily(Others),
Record a TargetMachine instead of a Reloc::Model. Addresses r270095's code review. llvm-svn: 270147
2016-05-20 06:07:57 +08:00
PICStyle(PICStyles::None), TM(TM), TargetTriple(TT),
Reformat a couple of functions for clarity. llvm-svn: 208248
2014-05-08 05:05:47 +08:00
StackAlignOverride(StackAlignOverride),
[X86] Add support for passing 'prefer-vector-width' function attribute into X86Subtarget and exposing via X86's getRegisterWidth TTI interface. This will cause the vectorizers to do some limiting of the vector widths they create. This is not a strict limit. There are reasons I know of that the loop vectorizer will generate larger vectors for. I've written this in such a way that the interface will only return a properly supported width(0/128/256/512) even if the attribute says something funny like 384 or 10. This has been split from D41895 with the remainder in a follow up commit. llvm-svn: 323015
2018-01-20 08:26:08 +08:00
PreferVectorWidthOverride(PreferVectorWidthOverride),
[X86] Don't make 512-bit vectors legal when preferred vector width is 256 bits and 512 bits aren't required This patch adds a new function attribute "required-vector-width" that can be set by the frontend to indicate the maximum vector width present in the original source code. The idea is that this would be set based on ABI requirements, intrinsics or explicit vector types being used, maybe simd pragmas, etc. The backend will then use this information to determine if its save to make 512-bit vectors illegal when the preference is for 256-bit vectors. For code that has no vectors in it originally and only get vectors through the loop and slp vectorizers this allows us to generate code largely similar to our AVX2 only output while still enabling AVX512 features like mask registers and gather/scatter. The loop vectorizer doesn't always obey TTI and will create oversized vectors with the expectation the backend will legalize it. In order to avoid changing the vectorizer and potentially harm our AVX2 codegen this patch tries to make the legalizer behavior similar. This is restricted to CPUs that support AVX512F and AVX512VL so that we have good fallback options to use 128 and 256-bit vectors and still get masking. I've qualified every place I could find in X86ISelLowering.cpp and added tests cases for many of them with 2 different values for the attribute to see the codegen differences. We still need to do frontend work for the attribute and teach the inliner how to merge it, etc. But this gets the codegen layer ready for it. Differential Revision: https://reviews.llvm.org/D42724 llvm-svn: 324834
2018-02-11 16:06:27 +08:00
RequiredVectorWidth(RequiredVectorWidth),
Reformat a couple of functions for clarity. llvm-svn: 208248
2014-05-08 05:05:47 +08:00
In64BitMode(TargetTriple.getArch() == Triple::x86_64),
In32BitMode(TargetTriple.getArch() == Triple::x86 &&
TargetTriple.getEnvironment() != Triple::CODE16),
In16BitMode(TargetTriple.getArch() == Triple::x86 &&
Move all of the x86 subtarget initialized variables down into the x86 subtarget from the x86 target machine. Should be no functional change. llvm-svn: 210479
2014-06-10 01:08:19 +08:00
TargetTriple.getEnvironment() == Triple::CODE16),
[globalisel][tablegen] Compute available feature bits correctly. Summary: Predicate<> now has a field to indicate how often it must be recomputed. Currently, there are two frequencies, per-module (RecomputePerFunction==0) and per-function (RecomputePerFunction==1). Per-function predicates are currently recomputed more frequently than necessary since the only predicate in this category is cheap to test. Per-module predicates are now computed in getSubtargetImpl() while per-function predicates are computed in selectImpl(). Tablegen now manages the PredicateBitset internally. It should only be necessary to add the required includes. Also fixed a problem revealed by the test case where constrainSelectedInstRegOperands() would attempt to tie operands that BuildMI had already tied. Reviewers: ab, qcolombet, t.p.northover, rovka, aditya_nandakumar Reviewed By: rovka Subscribers: kristof.beyls, igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D32491 llvm-svn: 301750
2017-04-30 01:30:09 +08:00
InstrInfo(initializeSubtargetDependencies(CPU, FS)), TLInfo(TM, *this),
[globalisel][tablegen] Demote OptForSize/OptForMinSize/ForCodeSize to per-function predicates. Summary: This causes them to be re-computed more often than necessary but resolves objections that were raised post-commit on r301750. Reviewers: qcolombet, ab, t.p.northover, rovka, kristof.beyls Reviewed By: qcolombet Subscribers: igorb, llvm-commits Differential Revision: https://reviews.llvm.org/D32861 llvm-svn: 303418
2017-05-19 19:08:33 +08:00
FrameLowering(*this, getStackAlignment()) {
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
// Determine the PICStyle based on the target selected.
Simplify PICStyles. The main difference is that StubDynamicNoPIC is gone. The dynamic-no-pic mode as the name implies is simply not pic. It is just conservative about what it assumes to be dso local. llvm-svn: 273222
2016-06-21 07:41:56 +08:00
if (!isPositionIndependent())
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
setPICStyle(PICStyles::None);
Simplify PICStyles. The main difference is that StubDynamicNoPIC is gone. The dynamic-no-pic mode as the name implies is simply not pic. It is just conservative about what it assumes to be dso local. llvm-svn: 273222
2016-06-21 07:41:56 +08:00
else if (is64Bit())
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
setPICStyle(PICStyles::RIPRel);
Simplify PICStyles. The main difference is that StubDynamicNoPIC is gone. The dynamic-no-pic mode as the name implies is simply not pic. It is just conservative about what it assumes to be dso local. llvm-svn: 273222
2016-06-21 07:41:56 +08:00
else if (isTargetCOFF())
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
setPICStyle(PICStyles::None);
Simplify PICStyles. The main difference is that StubDynamicNoPIC is gone. The dynamic-no-pic mode as the name implies is simply not pic. It is just conservative about what it assumes to be dso local. llvm-svn: 273222
2016-06-21 07:41:56 +08:00
else if (isTargetDarwin())
setPICStyle(PICStyles::StubPIC);
else if (isTargetELF())
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
setPICStyle(PICStyles::GOT);
[X86] Move GISel accessor initialization from TargetMachine to Subtarget. NFC llvm-svn: 306921
2017-07-01 08:45:50 +08:00
Reapply "[GlobalISel] Remove the GISelAccessor API." This reverts commit r310425, thus reapplying r310335 with a fix for link issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON. Original commit message: [GlobalISel] Remove the GISelAccessor API. Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. ---- The fix for the link issue consists in adding the GlobalISel library in the list of dependencies for the AArch64 unittests. This dependency comes from the use of AArch64Subtarget that needs to know how to destruct the GISel related APIs when being detroyed. Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and understand the problem. llvm-svn: 310969
2017-08-16 06:31:51 +08:00
CallLoweringInfo.reset(new X86CallLowering(*getTargetLowering()));
Legalizer.reset(new X86LegalizerInfo(*this, TM));
[X86] Move GISel accessor initialization from TargetMachine to Subtarget. NFC llvm-svn: 306921
2017-07-01 08:45:50 +08:00
auto *RBI = new X86RegisterBankInfo(*getRegisterInfo());
Reapply "[GlobalISel] Remove the GISelAccessor API." This reverts commit r310425, thus reapplying r310335 with a fix for link issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON. Original commit message: [GlobalISel] Remove the GISelAccessor API. Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. ---- The fix for the link issue consists in adding the GlobalISel library in the list of dependencies for the AArch64 unittests. This dependency comes from the use of AArch64Subtarget that needs to know how to destruct the GISel related APIs when being detroyed. Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and understand the problem. llvm-svn: 310969
2017-08-16 06:31:51 +08:00
RegBankInfo.reset(RBI);
InstSelector.reset(createX86InstructionSelector(TM, *this, *RBI));
Move some X86 subtarget configuration onto the subtarget that's being created. llvm-svn: 215271
2014-08-09 09:07:25 +08:00
}
Use the 'target-features' and 'target-cpu' attributes to reset the subtarget features. If two functions require different features (e.g., `-mno-sse' vs. `-msse') then we want to honor that, especially during LTO. We can do that by resetting the subtarget's features depending upon the 'target-feature' attribute. llvm-svn: 175314
2013-02-16 06:31:27 +08:00
[X86][GlobalISel] Add minimal call lowering support to the IRTranslator Summary: Add basic functionality to support call lowering for X86. Currently only supports functions which return void and take zero arguments. Inspired by commit 286573. Reviewers: ab, qcolombet, t.p.northover Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26593 llvm-svn: 286935
2016-11-15 14:34:33 +08:00
const CallLowering *X86Subtarget::getCallLowering() const {
Reapply "[GlobalISel] Remove the GISelAccessor API." This reverts commit r310425, thus reapplying r310335 with a fix for link issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON. Original commit message: [GlobalISel] Remove the GISelAccessor API. Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. ---- The fix for the link issue consists in adding the GlobalISel library in the list of dependencies for the AArch64 unittests. This dependency comes from the use of AArch64Subtarget that needs to know how to destruct the GISel related APIs when being detroyed. Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and understand the problem. llvm-svn: 310969
2017-08-16 06:31:51 +08:00
return CallLoweringInfo.get();
[X86][GlobalISel] Add minimal call lowering support to the IRTranslator Summary: Add basic functionality to support call lowering for X86. Currently only supports functions which return void and take zero arguments. Inspired by commit 286573. Reviewers: ab, qcolombet, t.p.northover Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26593 llvm-svn: 286935
2016-11-15 14:34:33 +08:00
}
const InstructionSelector *X86Subtarget::getInstructionSelector() const {
Reapply "[GlobalISel] Remove the GISelAccessor API." This reverts commit r310425, thus reapplying r310335 with a fix for link issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON. Original commit message: [GlobalISel] Remove the GISelAccessor API. Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. ---- The fix for the link issue consists in adding the GlobalISel library in the list of dependencies for the AArch64 unittests. This dependency comes from the use of AArch64Subtarget that needs to know how to destruct the GISel related APIs when being detroyed. Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and understand the problem. llvm-svn: 310969
2017-08-16 06:31:51 +08:00
return InstSelector.get();
[X86][GlobalISel] Add minimal call lowering support to the IRTranslator Summary: Add basic functionality to support call lowering for X86. Currently only supports functions which return void and take zero arguments. Inspired by commit 286573. Reviewers: ab, qcolombet, t.p.northover Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26593 llvm-svn: 286935
2016-11-15 14:34:33 +08:00
}
const LegalizerInfo *X86Subtarget::getLegalizerInfo() const {
Reapply "[GlobalISel] Remove the GISelAccessor API." This reverts commit r310425, thus reapplying r310335 with a fix for link issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON. Original commit message: [GlobalISel] Remove the GISelAccessor API. Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. ---- The fix for the link issue consists in adding the GlobalISel library in the list of dependencies for the AArch64 unittests. This dependency comes from the use of AArch64Subtarget that needs to know how to destruct the GISel related APIs when being detroyed. Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and understand the problem. llvm-svn: 310969
2017-08-16 06:31:51 +08:00
return Legalizer.get();
[X86][GlobalISel] Add minimal call lowering support to the IRTranslator Summary: Add basic functionality to support call lowering for X86. Currently only supports functions which return void and take zero arguments. Inspired by commit 286573. Reviewers: ab, qcolombet, t.p.northover Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26593 llvm-svn: 286935
2016-11-15 14:34:33 +08:00
}
const RegisterBankInfo *X86Subtarget::getRegBankInfo() const {
Reapply "[GlobalISel] Remove the GISelAccessor API." This reverts commit r310425, thus reapplying r310335 with a fix for link issue of the AArch64 unittests on Linux bots when BUILD_SHARED_LIBS is ON. Original commit message: [GlobalISel] Remove the GISelAccessor API. Its sole purpose was to avoid spreading around ifdefs related to building global-isel. Since r309990, GlobalISel is not optional anymore, thus, we can get rid of this mechanism all together. NFC. ---- The fix for the link issue consists in adding the GlobalISel library in the list of dependencies for the AArch64 unittests. This dependency comes from the use of AArch64Subtarget that needs to know how to destruct the GISel related APIs when being detroyed. Thanks to Bill Seurer and Ahmed Bougacha for helping me reproducing and understand the problem. llvm-svn: 310969
2017-08-16 06:31:51 +08:00
return RegBankInfo.get();
[X86][GlobalISel] Add minimal call lowering support to the IRTranslator Summary: Add basic functionality to support call lowering for X86. Currently only supports functions which return void and take zero arguments. Inspired by commit 286573. Reviewers: ab, qcolombet, t.p.northover Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26593 llvm-svn: 286935
2016-11-15 14:34:33 +08:00
}
Move Post RA Scheduling flag bit into SchedMachineModel Refactoring; no functional changes intended Removed PostRAScheduler bits from subtargets (X86, ARM). Added PostRAScheduler bit to MCSchedModel class. This bit is set by a CPU's scheduling model (if it exists). Removed enablePostRAScheduler() function from TargetSubtargetInfo and subclasses. Fixed the existing enablePostMachineScheduler() method to use the MCSchedModel (was just returning false!). Added methods to TargetSubtargetInfo to allow overrides for AntiDepBreakMode, CriticalPathRCs, and OptLevel for PostRAScheduling. Added enablePostRAScheduler() function to PostRAScheduler class which queries the subtarget for the above values. Preserved existing scheduler behavior for ARM, MIPS, PPC, and X86: a. ARM overrides the CPU's postRA settings by enabling postRA for any non-Thumb or Thumb2 subtarget. b. MIPS overrides the CPU's postRA settings by enabling postRA for everything. c. PPC overrides the CPU's postRA settings by enabling postRA for everything. d. X86 is the only target that actually has postRA specified via sched model info. Differential Revision: http://reviews.llvm.org/D4217 llvm-svn: 213101
2014-07-16 06:39:58 +08:00
bool X86Subtarget::enableEarlyIfConversion() const {
Fix compilation issues. llvm-svn: 209342
2014-05-22 07:51:57 +08:00
return hasCMov() && X86EarlyIfConv;
Make early if conversion dependent upon the subtarget and add a subtarget hook to enable. Unconditionally add to the pass pipeline for targets that might want to use it. No functional change. llvm-svn: 209340
2014-05-22 07:40:26 +08:00
}