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/X86.td

461 lines
23 KiB
TableGen
Raw Normal View History

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. llvm-svn: 150878
2012-02-18 20:03:15 +08:00
//===-- X86.td - Target definition file for the Intel X86 --*- tablegen -*-===//
Fix whitespace and tabs. llvm-svn: 129517
2011-04-14 22:33:36 +08:00
//
Added LLVM copyright header. llvm-svn: 9321
2003-10-21 23:17:13 +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.
Fix whitespace and tabs. llvm-svn: 129517
2011-04-14 22:33:36 +08:00
//
Added LLVM copyright header. llvm-svn: 9321
2003-10-21 23:17:13 +08:00
//===----------------------------------------------------------------------===//
Initial checkin of X86.td file llvm-svn: 7510
2003-08-03 23:47:49 +08:00
//
Add X86 LZCNT instruction. Including instruction selection support. llvm-svn: 141651
2011-10-11 14:44:02 +08:00
// This is a target description file for the Intel i386 architecture, referred
// to here as the "X86" architecture.
Initial checkin of X86.td file llvm-svn: 7510
2003-08-03 23:47:49 +08:00
//
//===----------------------------------------------------------------------===//
transition to using let instead of set llvm-svn: 7564
2003-08-04 12:59:56 +08:00
// Get the target-independent interfaces which we are implementing...
Initial checkin of X86.td file llvm-svn: 7510
2003-08-03 23:47:49 +08:00
//
Move target independent td files from lib/Target/ to include/llvm/Target so they can be distributed along with the header files. llvm-svn: 59953
2008-11-24 15:34:46 +08:00
include "llvm/Target/Target.td"
Initial checkin of X86.td file llvm-svn: 7510
2003-08-03 23:47:49 +08:00
Add Mode64Bit feature and sink it down to MC layer. llvm-svn: 134641
2011-07-08 05:06:52 +08:00
//===----------------------------------------------------------------------===//
(no commit message) llvm-svn: 162010
2012-08-16 11:50:04 +08:00
// X86 Subtarget state
Add Mode64Bit feature and sink it down to MC layer. llvm-svn: 134641
2011-07-08 05:06:52 +08:00
//
def Mode64Bit : SubtargetFeature<"64bit-mode", "In64BitMode", "true",
"64-bit mode (x86_64)">;
[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
def Mode32Bit : SubtargetFeature<"32bit-mode", "In32BitMode", "true",
"32-bit mode (80386)">;
def Mode16Bit : SubtargetFeature<"16bit-mode", "In16BitMode", "true",
"16-bit mode (i8086)">;
Add Mode64Bit feature and sink it down to MC layer. llvm-svn: 134641
2011-07-08 05:06:52 +08:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
//===----------------------------------------------------------------------===//
(no commit message) llvm-svn: 162010
2012-08-16 11:50:04 +08:00
// X86 Subtarget features
Add an "implies" field to features. This indicates that, if the current feature is set, then the features in the implied list should be set also. The opposite is also enforced: if a feature in the implied list isn't set, then the feature that owns that implies list shouldn't be set either. llvm-svn: 36756
2007-05-05 04:38:40 +08:00
//===----------------------------------------------------------------------===//
Add support for modeling whether or not the processor has support for conditional moves as a subtarget feature. This is the easy part of PR4841. llvm-svn: 80763
2009-09-02 13:53:04 +08:00
def FeatureCMOV : SubtargetFeature<"cmov","HasCMov", "true",
"Enable conditional move instructions">;
Add patterns for the x86 popcnt instruction. - Also adds a new POPCNT subtarget feature that is currently enabled if the target supports SSE4.2 (nehalem) or SSE4A (barcelona). llvm-svn: 120917
2010-12-05 04:32:23 +08:00
def FeaturePOPCNT : SubtargetFeature<"popcnt", "HasPOPCNT", "true",
"Support POPCNT instruction">;
Implement a feature (-vector-unaligned-mem) to allow targets to ignore alignment requirements for SIMD memory operands. This is useful on architectures like the AMD 10h that do not trap on unaligned references if a status bit is twiddled at startup time. llvm-svn: 93151
2010-01-12 00:29:42 +08:00
Add an "implies" field to features. This indicates that, if the current feature is set, then the features in the implied list should be set also. The opposite is also enforced: if a feature in the implied list isn't set, then the feature that owns that implies list shouldn't be set either. llvm-svn: 36756
2007-05-05 04:38:40 +08:00
def FeatureMMX : SubtargetFeature<"mmx","X86SSELevel", "MMX",
"Enable MMX instructions">;
def FeatureSSE1 : SubtargetFeature<"sse", "X86SSELevel", "SSE1",
"Enable SSE instructions",
Add support for modeling whether or not the processor has support for conditional moves as a subtarget feature. This is the easy part of PR4841. llvm-svn: 80763
2009-09-02 13:53:04 +08:00
// SSE codegen depends on cmovs, and all
Fix whitespace and tabs. llvm-svn: 129517
2011-04-14 22:33:36 +08:00
// SSE1+ processors support them.
Add support for modeling whether or not the processor has support for conditional moves as a subtarget feature. This is the easy part of PR4841. llvm-svn: 80763
2009-09-02 13:53:04 +08:00
[FeatureMMX, FeatureCMOV]>;
Add an "implies" field to features. This indicates that, if the current feature is set, then the features in the implied list should be set also. The opposite is also enforced: if a feature in the implied list isn't set, then the feature that owns that implies list shouldn't be set either. llvm-svn: 36756
2007-05-05 04:38:40 +08:00
def FeatureSSE2 : SubtargetFeature<"sse2", "X86SSELevel", "SSE2",
"Enable SSE2 instructions",
[FeatureSSE1]>;
def FeatureSSE3 : SubtargetFeature<"sse3", "X86SSELevel", "SSE3",
"Enable SSE3 instructions",
[FeatureSSE2]>;
def FeatureSSSE3 : SubtargetFeature<"ssse3", "X86SSELevel", "SSSE3",
"Enable SSSE3 instructions",
[FeatureSSE3]>;
Rename features to match what gcc and clang use. There is no advantage in being different and using the same names simplifies clang a bit. llvm-svn: 189141
2013-08-24 04:21:34 +08:00
def FeatureSSE41 : SubtargetFeature<"sse4.1", "X86SSELevel", "SSE41",
SSE 4.1 Intrinsics and detection llvm-svn: 46681
2008-02-03 15:18:54 +08:00
"Enable SSE 4.1 instructions",
[FeatureSSSE3]>;
Rename features to match what gcc and clang use. There is no advantage in being different and using the same names simplifies clang a bit. llvm-svn: 189141
2013-08-24 04:21:34 +08:00
def FeatureSSE42 : SubtargetFeature<"sse4.2", "X86SSELevel", "SSE42",
SSE 4.1 Intrinsics and detection llvm-svn: 46681
2008-02-03 15:18:54 +08:00
"Enable SSE 4.2 instructions",
Make SSE42 and SSE4A not imply POPCNT. POPCNT should be able to be disabled on its own without disabling SSE4.2 or SSE4A. llvm-svn: 147339
2011-12-29 23:51:45 +08:00
[FeatureSSE41]>;
Add an "implies" field to features. This indicates that, if the current feature is set, then the features in the implied list should be set also. The opposite is also enforced: if a feature in the implied list isn't set, then the feature that owns that implies list shouldn't be set either. llvm-svn: 36756
2007-05-05 04:38:40 +08:00
def Feature3DNow : SubtargetFeature<"3dnow", "X863DNowLevel", "ThreeDNow",
Add 3DNow! intrinsics. llvm-svn: 129551
2011-04-15 08:32:41 +08:00
"Enable 3DNow! instructions",
[FeatureMMX]>;
Add an "implies" field to features. This indicates that, if the current feature is set, then the features in the implied list should be set also. The opposite is also enforced: if a feature in the implied list isn't set, then the feature that owns that implies list shouldn't be set either. llvm-svn: 36756
2007-05-05 04:38:40 +08:00
def Feature3DNowA : SubtargetFeature<"3dnowa", "X863DNowLevel", "ThreeDNowA",
3DNowA implies 3DNow. 64-bit implies SSE1, SSE2, and I assume MMX. llvm-svn: 36860
2007-05-06 15:56:19 +08:00
"Enable 3DNow! Athlon instructions",
[Feature3DNow]>;
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
// All x86-64 hardware has SSE2, but we don't mark SSE2 as an implied
// feature, because SSE2 can be disabled (e.g. for compiling OS kernels)
// without disabling 64-bit mode.
3DNowA implies 3DNow. 64-bit implies SSE1, SSE2, and I assume MMX. llvm-svn: 36860
2007-05-06 15:56:19 +08:00
def Feature64Bit : SubtargetFeature<"64bit", "HasX86_64", "true",
all 64-bit cpus have cmov, this should fix CodeGen/X86/cmov.ll (at least) on non-x86 builders. llvm-svn: 98520
2010-03-15 06:24:34 +08:00
"Support 64-bit instructions",
[FeatureCMOV]>;
Rename this feature to "cx16" to match gcc's flag name. Apparently these strings are directly tied to the flag names in clang with no remapping in between? llvm-svn: 192044
2013-10-06 04:11:44 +08:00
def FeatureCMPXCHG16B : SubtargetFeature<"cx16", "HasCmpxchg16b", "true",
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. llvm-svn: 138660
2011-08-27 05:21:21 +08:00
"64-bit with cmpxchg16b",
[Feature64Bit]>;
Do not isel load folding bt instructions for pentium m, core, core2, and AMD processors. These are significantly slower than a load followed by a bt of a register. llvm-svn: 61557
2009-01-02 13:35:45 +08:00
def FeatureSlowBTMem : SubtargetFeature<"slow-bt-mem", "IsBTMemSlow", "true",
"Bit testing of memory is slow">;
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
def FeatureSlowSHLD : SubtargetFeature<"slow-shld", "IsSHLDSlow", "true",
"SHLD instruction is slow">;
Nehalem unaligned memory access is fast. llvm-svn: 100089
2010-04-01 13:58:17 +08:00
def FeatureFastUAMem : SubtargetFeature<"fast-unaligned-mem",
"IsUAMemFast", "true",
"Fast unaligned memory access">;
Update CPU capabilities for AMD machines - added processors k8-sse3, opteron-sse3, athlon64-sse3, amdfam10, and barcelona with appropriate sse3/4a levels - added FeatureSSE4A for amdfam10 processors in X86Subtarget: - added hasSSE4A - updated AutoDetectSubtargetFeatures to detect SSE4A - updated GetCurrentX86CPU to detect family 15 with sse3 as k8-sse3 and family 10h as amdfam10 New processor names match those used by gcc. Patch by Paul Redmond! llvm-svn: 72434
2009-05-27 05:04:35 +08:00
def FeatureSSE4A : SubtargetFeature<"sse4a", "HasSSE4A", "true",
Make FMA4 imply AVX so that YMM registers would be available. Necessitates removing from Bulldozer CPU types since it would enable AVX code generation implicitly. Also make SSE4A imply SSE3. Without some level of SSE implied, XMM registers wouldn't be legal. llvm-svn: 147369
2011-12-30 15:16:00 +08:00
"Support SSE 4a instructions",
[FeatureSSE3]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
Remove AVX hack in X86Subtarget. AVX/AVX2 are now treated as an SSE level. Predicate functions have been altered to maintain previous names and behavior. llvm-svn: 147770
2012-01-09 17:02:13 +08:00
def FeatureAVX : SubtargetFeature<"avx", "X86SSELevel", "AVX",
"Enable AVX instructions",
[FeatureSSE42]>;
def FeatureAVX2 : SubtargetFeature<"avx2", "X86SSELevel", "AVX2",
Add intrinsics and feature flag for read/write FS/GS base instructions. Also add AVX2 feature flag. llvm-svn: 143319
2011-10-31 03:57:21 +08:00
"Enable AVX2 instructions",
[FeatureAVX]>;
Rename mattr names for AVX-512 to from avx-512 -> avx512f, avx-512-pfi -> av512pf, avx-512-cdi -> avx512cd, avx-512-eri->avx512er. This matches better with official docs and what gcc patches appearto be using. I didn't touch the has* functions or the feature flag names to avoid change the td and lowering file while commits are still happening. llvm-svn: 188859
2013-08-21 11:57:57 +08:00
def FeatureAVX512 : SubtargetFeature<"avx512f", "X86SSELevel", "AVX512F",
I'm starting to commit KNL backend. I'll push patches one-by-one. This patch includes support for the extended register set XMM16-31, YMM16-31, ZMM0-31. The full ISA you can see here: http://software.intel.com/en-us/intel-isa-extensions llvm-svn: 187030
2013-07-24 19:02:47 +08:00
"Enable AVX-512 instructions",
[FeatureAVX2]>;
Rename mattr names for AVX-512 to from avx-512 -> avx512f, avx-512-pfi -> av512pf, avx-512-cdi -> avx512cd, avx-512-eri->avx512er. This matches better with official docs and what gcc patches appearto be using. I didn't touch the has* functions or the feature flag names to avoid change the td and lowering file while commits are still happening. llvm-svn: 188859
2013-08-21 11:57:57 +08:00
def FeatureERI : SubtargetFeature<"avx512er", "HasERI", "true",
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
"Enable AVX-512 Exponential and Reciprocal Instructions",
[FeatureAVX512]>;
Rename mattr names for AVX-512 to from avx-512 -> avx512f, avx-512-pfi -> av512pf, avx-512-cdi -> avx512cd, avx-512-eri->avx512er. This matches better with official docs and what gcc patches appearto be using. I didn't touch the has* functions or the feature flag names to avoid change the td and lowering file while commits are still happening. llvm-svn: 188859
2013-08-21 11:57:57 +08:00
def FeatureCDI : SubtargetFeature<"avx512cd", "HasCDI", "true",
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
"Enable AVX-512 Conflict Detection Instructions",
[FeatureAVX512]>;
Rename mattr names for AVX-512 to from avx-512 -> avx512f, avx-512-pfi -> av512pf, avx-512-cdi -> avx512cd, avx-512-eri->avx512er. This matches better with official docs and what gcc patches appearto be using. I didn't touch the has* functions or the feature flag names to avoid change the td and lowering file while commits are still happening. llvm-svn: 188859
2013-08-21 11:57:57 +08:00
def FeaturePFI : SubtargetFeature<"avx512pf", "HasPFI", "true",
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
"Enable AVX-512 PreFetch Instructions",
[FeatureAVX512]>;
[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
def FeatureDQI : SubtargetFeature<"avx512dq", "HasDQI", "true",
"Enable AVX-512 Doubleword and Quadword Instructions",
[FeatureAVX512]>;
def FeatureBWI : SubtargetFeature<"avx512bw", "HasBWI", "true",
"Enable AVX-512 Byte and Word Instructions",
[FeatureAVX512]>;
def FeatureVLX : SubtargetFeature<"avx512vl", "HasVLX", "true",
"Enable AVX-512 Vector Length eXtensions",
[FeatureAVX512]>;
X86: Rename the CLMUL target feature to PCLMUL. It was renamed in gcc/gas a while ago and causes all kinds of confusion because it was named differently in llvm and clang. llvm-svn: 157745
2012-05-31 22:34:17 +08:00
def FeaturePCLMUL : SubtargetFeature<"pclmul", "HasPCLMUL", "true",
"Enable packed carry-less multiplication instructions",
Make CLMUL and AES imply SSE2 since its needed to legalize the type. llvm-svn: 155888
2012-05-01 13:28:32 +08:00
[FeatureSSE2]>;
Rename FMA3 feature flag to just FMA to match gcc so it can be added to clang. llvm-svn: 157903
2012-06-04 02:58:46 +08:00
def FeatureFMA : SubtargetFeature<"fma", "HasFMA", "true",
Make FMA3 imply AVX needs to be enabled. Particularly because 256-bit types aren't valid unless AVX is enabled. llvm-svn: 147349
2011-12-30 03:46:19 +08:00
"Enable three-operand fused multiple-add",
[FeatureAVX]>;
Add feature flags for AVX and FMA and fix some SSE4A feature flag initialization problems. llvm-svn: 74350
2009-06-27 06:46:54 +08:00
def FeatureFMA4 : SubtargetFeature<"fma4", "HasFMA4", "true",
Make FMA4 imply AVX so that YMM registers would be available. Necessitates removing from Bulldozer CPU types since it would enable AVX code generation implicitly. Also make SSE4A imply SSE3. Without some level of SSE implied, XMM registers wouldn't be legal. llvm-svn: 147369
2011-12-30 15:16:00 +08:00
"Enable four-operand fused multiple-add",
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. llvm-svn: 155897
2012-05-01 14:54:48 +08:00
[FeatureAVX, FeatureSSE4A]>;
Make FMA4 imply AVX so that YMM registers would be available. Necessitates removing from Bulldozer CPU types since it would enable AVX code generation implicitly. Also make SSE4A imply SSE3. Without some level of SSE implied, XMM registers wouldn't be legal. llvm-svn: 147369
2011-12-30 15:16:00 +08:00
def FeatureXOP : SubtargetFeature<"xop", "HasXOP", "true",
Make XOP imply AVX as its needed to legalize the registers types. llvm-svn: 155891
2012-05-01 13:41:41 +08:00
"Enable XOP instructions",
Patch to enable FMA on bdver2 target. Make XOP feature enable FMA4 as well. llvm-svn: 162012
2012-08-16 12:04:02 +08:00
[FeatureFMA4]>;
Implement a feature (-vector-unaligned-mem) to allow targets to ignore alignment requirements for SIMD memory operands. This is useful on architectures like the AMD 10h that do not trap on unaligned references if a status bit is twiddled at startup time. llvm-svn: 93151
2010-01-12 00:29:42 +08:00
def FeatureVectorUAMem : SubtargetFeature<"vector-unaligned-mem",
"HasVectorUAMem", "true",
"Allow unaligned memory operands on vector/SIMD instructions">;
Separate out the AES-NI instructions from the SSE4.2 instructions. Add a new subtarget option for AES and check for the support. Add "westmere" line of processors and add AES-NI support to the core i7. Add a couple of TODOs for information I couldn't verify. llvm-svn: 100231
2010-04-03 05:54:27 +08:00
def FeatureAES : SubtargetFeature<"aes", "HasAES", "true",
Make CLMUL and AES imply SSE2 since its needed to legalize the type. llvm-svn: 155888
2012-05-01 13:28:32 +08:00
"Enable AES instructions",
[FeatureSSE2]>;
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
def FeatureTBM : SubtargetFeature<"tbm", "HasTBM", "true",
"Enable TBM instructions">;
Add support for MOVBE and RDRAND instructions for the assembler and disassembler. Includes feature flag checking, but no instrinsic support. Fixes PR10832, PR11026 and PR11027. llvm-svn: 141007
2011-10-04 01:28:23 +08:00
def FeatureMOVBE : SubtargetFeature<"movbe", "HasMOVBE", "true",
"Support MOVBE instruction">;
Rename features to match what gcc and clang use. There is no advantage in being different and using the same names simplifies clang a bit. llvm-svn: 189141
2013-08-24 04:21:34 +08:00
def FeatureRDRAND : SubtargetFeature<"rdrnd", "HasRDRAND", "true",
Add support for MOVBE and RDRAND instructions for the assembler and disassembler. Includes feature flag checking, but no instrinsic support. Fixes PR10832, PR11026 and PR11027. llvm-svn: 141007
2011-10-04 01:28:23 +08:00
"Support RDRAND instruction">;
Add Ivy Bridge 16-bit floating point conversion instructions for the X86 disassembler. llvm-svn: 141505
2011-10-09 15:31:39 +08:00
def FeatureF16C : SubtargetFeature<"f16c", "HasF16C", "true",
Make F16C feature flag imply AVX rather than just checking both at the patterns. llvm-svn: 190775
2013-09-16 12:29:58 +08:00
"Support 16-bit floating point conversion instructions",
[FeatureAVX]>;
Add intrinsics and feature flag for read/write FS/GS base instructions. Also add AVX2 feature flag. llvm-svn: 143319
2011-10-31 03:57:21 +08:00
def FeatureFSGSBase : SubtargetFeature<"fsgsbase", "HasFSGSBase", "true",
"Support FS/GS Base instructions">;
Add X86 LZCNT instruction. Including instruction selection support. llvm-svn: 141651
2011-10-11 14:44:02 +08:00
def FeatureLZCNT : SubtargetFeature<"lzcnt", "HasLZCNT", "true",
"Support LZCNT instruction">;
Add X86 TZCNT instruction and patterns to select it. Also added core-avx2 processor which is gcc's name for Haswell. llvm-svn: 141939
2011-10-14 11:21:46 +08:00
def FeatureBMI : SubtargetFeature<"bmi", "HasBMI", "true",
"Support BMI instructions">;
Add X86 BZHI instruction as well as BMI2 feature detection. llvm-svn: 142122
2011-10-16 15:55:05 +08:00
def FeatureBMI2 : SubtargetFeature<"bmi2", "HasBMI2", "true",
"Support BMI2 instructions">;
Add support of RTM from TSX extension - Add RTM code generation support throught 3 X86 intrinsics: xbegin()/xend() to start/end a transaction region, and xabort() to abort a tranaction region llvm-svn: 167573
2012-11-08 15:28:54 +08:00
def FeatureRTM : SubtargetFeature<"rtm", "HasRTM", "true",
"Support RTM instructions">;
Add HLE target feature llvm-svn: 178082
2013-03-27 06:46:02 +08:00
def FeatureHLE : SubtargetFeature<"hle", "HasHLE", "true",
"Support HLE">;
added basic support for Intel ADX instructions -feature flag, instructions definitions, test cases llvm-svn: 175196
2013-02-15 03:08:21 +08:00
def FeatureADX : SubtargetFeature<"adx", "HasADX", "true",
"Support ADX instructions">;
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
def FeatureSHA : SubtargetFeature<"sha", "HasSHA", "true",
"Enable SHA instructions",
[FeatureSSE2]>;
Add PREFETCHW codegen support - Add 'PRFCHW' feature defined in AVX2 ISA extension llvm-svn: 178040
2013-03-27 01:47:11 +08:00
def FeaturePRFCHW : SubtargetFeature<"prfchw", "HasPRFCHW", "true",
"Support PRFCHW instructions">;
Add support of RDSEED defined in AVX2 extension llvm-svn: 178314
2013-03-29 07:41:26 +08:00
def FeatureRDSEED : SubtargetFeature<"rdseed", "HasRDSEED", "true",
"Support RDSEED instruction">;
Use LEA to adjust stack ptr for Atom. Patch by Andy Zhang. llvm-svn: 150008
2012-02-08 06:50:41 +08:00
def FeatureLeaForSP : SubtargetFeature<"lea-sp", "UseLeaForSP", "true",
"Use LEA for adjusting the stack pointer">;
Generic Bypass Slow Div - CodeGenPrepare pass for identifying div/rem ops - Backend specifies the type mapping using addBypassSlowDivType - Enabled only for Intel Atom with O2 32-bit -> 8-bit - Replace IDIV with instructions which test its value and use DIVB if the value is positive and less than 256. - In the case when the quotient and remainder of a divide are used a DIV and a REM instruction will be present in the IR. In the non-Atom case they are both lowered to IDIVs and CSE removes the redundant IDIV instruction, using the quotient and remainder from the first IDIV. However, due to this optimization CSE is not able to eliminate redundant IDIV instructions because they are located in different basic blocks. This is overcome by calculating both the quotient (DIV) and remainder (REM) in each basic block that is inserted by the optimization and reusing the result values when a subsequent DIV or REM instruction uses the same operands. - Test cases check for the presents of the optimization when calculating either the quotient, remainder, or both. Patch by Tyler Nowicki! llvm-svn: 163150
2012-09-05 02:22:17 +08:00
def FeatureSlowDivide : SubtargetFeature<"idiv-to-divb",
Pad Short Functions for Intel Atom The current Intel Atom microarchitecture has a feature whereby when a function returns early then it is slightly faster to execute a sequence of NOP instructions to wait until the return address is ready, as opposed to simply stalling on the ret instruction until the return address is ready. When compiling for X86 Atom only, this patch will run a pass, called "X86PadShortFunction" which will add NOP instructions where less than four cycles elapse between function entry and return. It includes tests. This patch has been updated to address Nadav's review comments - Optimize only at >= O1 and don't do optimization if -Os is set - Stores MachineBasicBlock* instead of BBNum - Uses DenseMap instead of std::map - Fixes placement of braces Patch by Andy Zhang. llvm-svn: 171879
2013-01-09 02:27:24 +08:00
"HasSlowDivide", "true",
"Use small divide for positive values less than 256">;
def FeaturePadShortFunctions : SubtargetFeature<"pad-short-functions",
"PadShortFunctions", "true",
"Pad short functions">;
For the current Atom processor, the fastest way to handle a call indirect through a memory address is to load the memory address into a register and then call indirect through the register. This patch implements this improvement by modifying SelectionDAG to force a function address which is a memory reference to be loaded into a virtual register. Patch by Sriram Murali. llvm-svn: 178171
2013-03-28 03:14:02 +08:00
def FeatureCallRegIndirect : SubtargetFeature<"call-reg-indirect",
"CallRegIndirect", "true",
"Call register indirect">;
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
def FeatureLEAUsesAG : SubtargetFeature<"lea-uses-ag", "LEAUsesAG", "true",
"LEA instruction needs inputs at AG stage">;
[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
def FeatureSlowLEA : SubtargetFeature<"slow-lea", "SlowLEA", "true",
"LEA instruction with certain arguments is slow">;
[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
def FeatureSlowIncDec : SubtargetFeature<"slow-incdec", "SlowIncDec", "true",
"INC and DEC instructions are slower than ADD and SUB">;
Add feature flags for AVX and FMA and fix some SSE4A feature flag initialization problems. llvm-svn: 74350
2009-06-27 06:46:54 +08:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
//===----------------------------------------------------------------------===//
// X86 processors supported.
//===----------------------------------------------------------------------===//
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
include "X86Schedule.td"
def ProcIntelAtom : SubtargetFeature<"atom", "X86ProcFamily", "IntelAtom",
"Intel Atom processors">;
Adds support for Atom Silvermont (SLM) - -march=slm Implements Instruction scheduler latencies for Silvermont, using latencies from the Intel Silvermont Optimization Guide. Auto detects SLM. Turns on post RA scheduler when generating code for SLM. llvm-svn: 190717
2013-09-14 03:23:28 +08:00
def ProcIntelSLM : SubtargetFeature<"slm", "X86ProcFamily", "IntelSLM",
"Intel Silvermont processors">;
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
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
class Proc<string Name, list<SubtargetFeature> Features>
I'm introducing a new machine model to simultaneously allow simple subtarget CPU descriptions and support new features of MachineScheduler. MachineModel has three categories of data: 1) Basic properties for coarse grained instruction cost model. 2) Scheduler Read/Write resources for simple per-opcode and operand cost model (TBD). 3) Instruction itineraties for detailed per-cycle reservation tables. These will all live side-by-side. Any subtarget can use any combination of them. Instruction itineraries will not change in the near term. In the long run, I expect them to only be relevant for in-order VLIW machines that have complex contraints and require a precise scheduling/bundling model. Once itineraries are only actively used by VLIW-ish targets, they could be replaced by something more appropriate for those targets. This tablegen backend rewrite sets things up for introducing MachineModel type #2: per opcode/operand cost model. llvm-svn: 159891
2012-07-07 12:00:00 +08:00
: ProcessorModel<Name, GenericModel, Features>;
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
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
def : Proc<"generic", []>;
def : Proc<"i386", []>;
def : Proc<"i486", []>;
Accept -march=i586, because gcc does (a synonym for pentium). Fixes gcc.target/i386/20000720-1.c gcc.target/i386/pr26826.c llvm-svn: 57528
2008-10-15 06:06:33 +08:00
def : Proc<"i586", []>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
def : Proc<"pentium", []>;
def : Proc<"pentium-mmx", [FeatureMMX]>;
def : Proc<"i686", []>;
Add support for modeling whether or not the processor has support for conditional moves as a subtarget feature. This is the easy part of PR4841. llvm-svn: 80763
2009-09-02 13:53:04 +08:00
def : Proc<"pentiumpro", [FeatureCMOV]>;
def : Proc<"pentium2", [FeatureMMX, FeatureCMOV]>;
We only need to specify the most-implied feature for an architecture. llvm-svn: 37275
2007-05-22 13:15:37 +08:00
def : Proc<"pentium3", [FeatureSSE1]>;
Add pentium{3,4}m cpus. Patch by Alexander Best! llvm-svn: 130749
2011-05-03 11:42:50 +08:00
def : Proc<"pentium3m", [FeatureSSE1, FeatureSlowBTMem]>;
Do not isel load folding bt instructions for pentium m, core, core2, and AMD processors. These are significantly slower than a load followed by a bt of a register. llvm-svn: 61557
2009-01-02 13:35:45 +08:00
def : Proc<"pentium-m", [FeatureSSE2, FeatureSlowBTMem]>;
We only need to specify the most-implied feature for an architecture. llvm-svn: 37275
2007-05-22 13:15:37 +08:00
def : Proc<"pentium4", [FeatureSSE2]>;
Add pentium{3,4}m cpus. Patch by Alexander Best! llvm-svn: 130749
2011-05-03 11:42:50 +08:00
def : Proc<"pentium4m", [FeatureSSE2, FeatureSlowBTMem]>;
[x86] Make the 'x86-64' cpu, what I see as and many use as the generic default architecture for reasonable modern x86 processors, actually be modern. This processor model should essentially be "tuned" for modern x86 chips as much as possible without undue penalties on any specific architecture. Previously we weren't even using the nice scheduling models. There are a few other tweaks needed here, but this change at least I have benchmarked across a decent swatch of chips (intel's clovertown, westmere, and sandybridge; amd's istanbul) and seen no significant regressions. If anyone has suggested ways to test this, just let me know. Somewhat alarmingly, no existing tests failed. llvm-svn: 208230
2014-05-08 01:37:03 +08:00
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
// Intel Core Duo.
def : ProcessorModel<"yonah", SandyBridgeModel,
[FeatureSSE3, FeatureSlowBTMem]>;
// NetBurst.
def : Proc<"prescott", [FeatureSSE3, FeatureSlowBTMem]>;
def : Proc<"nocona", [FeatureSSE3, FeatureCMPXCHG16B, FeatureSlowBTMem]>;
// Intel Core 2 Solo/Duo.
def : ProcessorModel<"core2", SandyBridgeModel,
[FeatureSSSE3, FeatureCMPXCHG16B, FeatureSlowBTMem]>;
def : ProcessorModel<"penryn", SandyBridgeModel,
[FeatureSSE41, FeatureCMPXCHG16B, FeatureSlowBTMem]>;
// Atom.
def : ProcessorModel<"atom", AtomModel,
[ProcIntelAtom, FeatureSSSE3, FeatureCMPXCHG16B,
FeatureMOVBE, FeatureSlowBTMem, FeatureLeaForSP,
For the current Atom processor, the fastest way to handle a call indirect through a memory address is to load the memory address into a register and then call indirect through the register. This patch implements this improvement by modifying SelectionDAG to force a function address which is a memory reference to be loaded into a virtual register. Patch by Sriram Murali. llvm-svn: 178171
2013-03-28 03:14:02 +08:00
FeatureSlowDivide,
FeatureCallRegIndirect,
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
FeatureLEAUsesAG,
For the current Atom processor, the fastest way to handle a call indirect through a memory address is to load the memory address into a register and then call indirect through the register. This patch implements this improvement by modifying SelectionDAG to force a function address which is a memory reference to be loaded into a virtual register. Patch by Sriram Murali. llvm-svn: 178171
2013-03-28 03:14:02 +08:00
FeaturePadShortFunctions]>;
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
Adds support for Atom Silvermont (SLM) - -march=slm Implements Instruction scheduler latencies for Silvermont, using latencies from the Intel Silvermont Optimization Guide. Auto detects SLM. Turns on post RA scheduler when generating code for SLM. llvm-svn: 190717
2013-09-14 03:23:28 +08:00
// Atom Silvermont.
def : ProcessorModel<"slm", SLMModel, [ProcIntelSLM,
FeatureSSE42, FeatureCMPXCHG16B,
FeatureMOVBE, FeaturePOPCNT,
FeaturePCLMUL, FeatureAES,
FeatureCallRegIndirect,
FeaturePRFCHW,
[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
FeatureSlowLEA, FeatureSlowIncDec,
Enable FeatureFastUAMem for Silvermont processor Differential Revision: http://llvm-reviews.chandlerc.com/D2982 llvm-svn: 203218
2014-03-07 17:03:49 +08:00
FeatureSlowBTMem, FeatureFastUAMem]>;
Separate out the AES-NI instructions from the SSE4.2 instructions. Add a new subtarget option for AES and check for the support. Add "westmere" line of processors and add AES-NI support to the core i7. Add a couple of TODOs for information I couldn't verify. llvm-svn: 100231
2010-04-03 05:54:27 +08:00
// "Arrandale" along with corei3 and corei5
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
def : ProcessorModel<"corei7", SandyBridgeModel,
[FeatureSSE42, FeatureCMPXCHG16B, FeatureSlowBTMem,
FeatureFastUAMem, FeaturePOPCNT, FeatureAES]>;
def : ProcessorModel<"nehalem", SandyBridgeModel,
[FeatureSSE42, FeatureCMPXCHG16B, FeatureSlowBTMem,
FeatureFastUAMem, FeaturePOPCNT]>;
Separate out the AES-NI instructions from the SSE4.2 instructions. Add a new subtarget option for AES and check for the support. Add "westmere" line of processors and add AES-NI support to the core i7. Add a couple of TODOs for information I couldn't verify. llvm-svn: 100231
2010-04-03 05:54:27 +08:00
// Westmere is a similar machine to nehalem with some additional features.
// Westmere is the corei3/i5/i7 path from nehalem to sandybridge
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
def : ProcessorModel<"westmere", SandyBridgeModel,
[FeatureSSE42, FeatureCMPXCHG16B, FeatureSlowBTMem,
FeatureFastUAMem, FeaturePOPCNT, FeatureAES,
FeaturePCLMUL]>;
X86: Add a subtarget definition for core-avx-i, which is GCC's name for ivy bridge. llvm-svn: 141571
2011-10-11 03:35:07 +08:00
// Sandy Bridge
Formalize the notion that AVX and SSE are non-overlapping extensions from the compiler's point of view. Per email discussion, we either want to always use VEX-prefixed instructions or never use them, and are taking "HasAVX" to mean "Always use VEX". Passing -mattr=-avx,+sse42 should serve to restore legacy SSE support when desirable. llvm-svn: 121439
2010-12-10 08:26:57 +08:00
// SSE is not listed here since llvm treats AVX as a reimplementation of SSE,
// rather than a superset.
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
def : ProcessorModel<"corei7-avx", SandyBridgeModel,
[FeatureAVX, FeatureCMPXCHG16B, FeatureFastUAMem,
FeaturePOPCNT, FeatureAES, FeaturePCLMUL]>;
X86: Add a subtarget definition for core-avx-i, which is GCC's name for ivy bridge. llvm-svn: 141571
2011-10-11 03:35:07 +08:00
// Ivy Bridge
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
def : ProcessorModel<"core-avx-i", SandyBridgeModel,
[FeatureAVX, FeatureCMPXCHG16B, FeatureFastUAMem,
FeaturePOPCNT, FeatureAES, FeaturePCLMUL, FeatureRDRAND,
FeatureF16C, FeatureFSGSBase]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
Add X86 TZCNT instruction and patterns to select it. Also added core-avx2 processor which is gcc's name for Haswell. llvm-svn: 141939
2011-10-14 11:21:46 +08:00
// Haswell
Add the Haswell machine model. llvm-svn: 178301
2013-03-29 06:34:46 +08:00
def : ProcessorModel<"core-avx2", HaswellModel,
Enable SandyBridgeModel for all modern Intel P6 descendants. All Intel CPUs since Yonah look a lot alike, at least at the granularity of the scheduling models. We can add more accurate models for processors that aren't Sandy Bridge if required. Haswell will probably need its own. The Atom processor and anything based on NetBurst is completely different. So are the non-Intel chips. llvm-svn: 178080
2013-03-27 06:19:12 +08:00
[FeatureAVX2, FeatureCMPXCHG16B, FeatureFastUAMem,
FeaturePOPCNT, FeatureAES, FeaturePCLMUL, FeatureRDRAND,
FeatureF16C, FeatureFSGSBase, FeatureMOVBE, FeatureLZCNT,
Add HLE target feature llvm-svn: 178082
2013-03-27 06:46:02 +08:00
FeatureBMI, FeatureBMI2, FeatureFMA, FeatureRTM,
FeatureHLE]>;
Add X86 TZCNT instruction and patterns to select it. Also added core-avx2 processor which is gcc's name for Haswell. llvm-svn: 141939
2011-10-14 11:21:46 +08:00
I'm starting to commit KNL backend. I'll push patches one-by-one. This patch includes support for the extended register set XMM16-31, YMM16-31, ZMM0-31. The full ISA you can see here: http://software.intel.com/en-us/intel-isa-extensions llvm-svn: 187030
2013-07-24 19:02:47 +08:00
// KNL
// FIXME: define KNL model
def : ProcessorModel<"knl", HaswellModel,
[FeatureAVX512, FeatureERI, FeatureCDI, FeaturePFI,
FeatureCMPXCHG16B, FeatureFastUAMem, FeaturePOPCNT,
FeatureAES, FeaturePCLMUL, FeatureRDRAND, FeatureF16C,
FeatureFSGSBase, FeatureMOVBE, FeatureLZCNT, FeatureBMI,
AVX-512: dec/inc instructions are slow on KNL After Alexey Volkov, I'm adding the same property for KNL, that prefers ADD/SUB instead of INC/DEC. Added a test. llvm-svn: 212178
2014-07-02 22:11:05 +08:00
FeatureBMI2, FeatureFMA, FeatureRTM, FeatureHLE,
FeatureSlowIncDec]>;
I'm starting to commit KNL backend. I'll push patches one-by-one. This patch includes support for the extended register set XMM16-31, YMM16-31, ZMM0-31. The full ISA you can see here: http://software.intel.com/en-us/intel-isa-extensions llvm-svn: 187030
2013-07-24 19:02:47 +08:00
[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
// SKX
// FIXME: define SKX model
def : ProcessorModel<"skx", HaswellModel,
[FeatureAVX512, FeatureCDI,
FeatureDQI, FeatureBWI, FeatureVLX,
FeatureCMPXCHG16B, FeatureFastUAMem, FeaturePOPCNT,
FeatureAES, FeaturePCLMUL, FeatureRDRAND, FeatureF16C,
FeatureFSGSBase, FeatureMOVBE, FeatureLZCNT, FeatureBMI,
FeatureBMI2, FeatureFMA, FeatureRTM, FeatureHLE,
FeatureSlowIncDec]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
def : Proc<"k6", [FeatureMMX]>;
Add 3DNow! intrinsics. llvm-svn: 129551
2011-04-15 08:32:41 +08:00
def : Proc<"k6-2", [Feature3DNow]>;
def : Proc<"k6-3", [Feature3DNow]>;
Test commit Removed whitespace llvm-svn: 203216
2014-03-07 16:28:44 +08:00
def : Proc<"athlon", [Feature3DNowA, FeatureSlowBTMem,
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
FeatureSlowSHLD]>;
def : Proc<"athlon-tbird", [Feature3DNowA, FeatureSlowBTMem,
FeatureSlowSHLD]>;
def : Proc<"athlon-4", [FeatureSSE1, Feature3DNowA, FeatureSlowBTMem,
FeatureSlowSHLD]>;
def : Proc<"athlon-xp", [FeatureSSE1, Feature3DNowA, FeatureSlowBTMem,
FeatureSlowSHLD]>;
def : Proc<"athlon-mp", [FeatureSSE1, Feature3DNowA, FeatureSlowBTMem,
FeatureSlowSHLD]>;
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
def : Proc<"k8", [FeatureSSE2, Feature3DNowA, Feature64Bit,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
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
def : Proc<"opteron", [FeatureSSE2, Feature3DNowA, Feature64Bit,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
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
def : Proc<"athlon64", [FeatureSSE2, Feature3DNowA, Feature64Bit,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
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
def : Proc<"athlon-fx", [FeatureSSE2, Feature3DNowA, Feature64Bit,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. llvm-svn: 138660
2011-08-27 05:21:21 +08:00
def : Proc<"k8-sse3", [FeatureSSE3, Feature3DNowA, FeatureCMPXCHG16B,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. llvm-svn: 138660
2011-08-27 05:21:21 +08:00
def : Proc<"opteron-sse3", [FeatureSSE3, Feature3DNowA, FeatureCMPXCHG16B,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. llvm-svn: 138660
2011-08-27 05:21:21 +08:00
def : Proc<"athlon64-sse3", [FeatureSSE3, Feature3DNowA, FeatureCMPXCHG16B,
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
FeatureSlowBTMem, FeatureSlowSHLD]>;
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. llvm-svn: 155897
2012-05-01 14:54:48 +08:00
def : Proc<"amdfam10", [FeatureSSE4A,
X86: Turns out bulldozer also supports sse42 and lzcnt. While at it remove the barcelona/instanbul/shanghai subtargets, they're unsupported by GCC and look pretty broken. llvm-svn: 145494
2011-11-30 23:48:16 +08:00
Feature3DNowA, FeatureCMPXCHG16B, FeatureLZCNT,
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
FeaturePOPCNT, FeatureSlowBTMem,
FeatureSlowSHLD]>;
Add definitions for AMD's bobcat (aka btver1) llvm-svn: 147846
2012-01-10 19:50:02 +08:00
// Bobcat
def : Proc<"btver1", [FeatureSSSE3, FeatureSSE4A, FeatureCMPXCHG16B,
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
FeaturePRFCHW, FeatureLZCNT, FeaturePOPCNT,
FeatureSlowSHLD]>;
X86: Add target description for btver2; make autodetection logic aware of AVX. llvm-svn: 181005
2013-05-03 18:20:08 +08:00
// Jaguar
def : Proc<"btver2", [FeatureAVX, FeatureSSE4A, FeatureCMPXCHG16B,
Enabling 3DNow! prefetch instruction for a few AMD processors: bobcat, jaguar, bulldozer and piledriver. Support for the instruction itself seems to have already been added in r178040. Differential Revision: http://llvm-reviews.chandlerc.com/D1933 llvm-svn: 192828
2013-10-17 03:04:11 +08:00
FeaturePRFCHW, FeatureAES, FeaturePCLMUL,
FeatureBMI, FeatureF16C, FeatureMOVBE,
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
FeatureLZCNT, FeaturePOPCNT, FeatureSlowSHLD]>;
Add definitions for AMD's bobcat (aka btver1) llvm-svn: 147846
2012-01-10 19:50:02 +08:00
// Bulldozer
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. llvm-svn: 155897
2012-05-01 14:54:48 +08:00
def : Proc<"bdver1", [FeatureXOP, FeatureFMA4, FeatureCMPXCHG16B,
Enabling 3DNow! prefetch instruction for a few AMD processors: bobcat, jaguar, bulldozer and piledriver. Support for the instruction itself seems to have already been added in r178040. Differential Revision: http://llvm-reviews.chandlerc.com/D1933 llvm-svn: 192828
2013-10-17 03:04:11 +08:00
FeatureAES, FeaturePRFCHW, FeaturePCLMUL,
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
FeatureLZCNT, FeaturePOPCNT, FeatureSlowSHLD]>;
X86: Add target description for btver2; make autodetection logic aware of AVX. llvm-svn: 181005
2013-05-03 18:20:08 +08:00
// Piledriver
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. llvm-svn: 155897
2012-05-01 14:54:48 +08:00
def : Proc<"bdver2", [FeatureXOP, FeatureFMA4, FeatureCMPXCHG16B,
Enabling 3DNow! prefetch instruction for a few AMD processors: bobcat, jaguar, bulldozer and piledriver. Support for the instruction itself seems to have already been added in r178040. Differential Revision: http://llvm-reviews.chandlerc.com/D1933 llvm-svn: 192828
2013-10-17 03:04:11 +08:00
FeatureAES, FeaturePRFCHW, FeaturePCLMUL,
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. llvm-svn: 155897
2012-05-01 14:54:48 +08:00
FeatureF16C, FeatureLZCNT,
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
FeaturePOPCNT, FeatureBMI, FeatureTBM,
FeatureFMA, FeatureSlowSHLD]>;
X86: Add a description for AMD bdver3 aka Steamroller. This is just bdver2 + FSGSBase. llvm-svn: 193984
2013-11-04 18:29:20 +08:00
// Steamroller
def : Proc<"bdver3", [FeatureXOP, FeatureFMA4, FeatureCMPXCHG16B,
FeatureAES, FeaturePRFCHW, FeaturePCLMUL,
FeatureF16C, FeatureLZCNT,
FeaturePOPCNT, FeatureBMI, FeatureTBM,
FeatureFMA, FeatureFSGSBase]>;
Add a description for AMD's bdver4 (aka Excavator). This is just bdver3 + AVX2 + BMI2. llvm-svn: 207847
2014-05-02 23:47:07 +08:00
// Excavator
def : Proc<"bdver4", [FeatureAVX2, FeatureXOP, FeatureFMA4,
FeatureCMPXCHG16B, FeatureAES, FeaturePRFCHW,
FeaturePCLMUL, FeatureF16C, FeatureLZCNT,
FeaturePOPCNT, FeatureBMI, FeatureBMI2,
FeatureTBM, FeatureFMA, FeatureFSGSBase]>;
Add support for AMD Geode. llvm-svn: 163710
2012-09-12 22:36:02 +08:00
def : Proc<"geode", [Feature3DNowA]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
def : Proc<"winchip-c6", [FeatureMMX]>;
Add 3DNow! intrinsics. llvm-svn: 129551
2011-04-15 08:32:41 +08:00
def : Proc<"winchip2", [Feature3DNow]>;
def : Proc<"c3", [Feature3DNow]>;
We only need to specify the most-implied feature for an architecture. llvm-svn: 37275
2007-05-22 13:15:37 +08:00
def : Proc<"c3-2", [FeatureSSE1]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. llvm-svn: 30764
2006-10-06 17:17:41 +08:00
[x86] Make the 'x86-64' cpu, what I see as and many use as the generic default architecture for reasonable modern x86 processors, actually be modern. This processor model should essentially be "tuned" for modern x86 chips as much as possible without undue penalties on any specific architecture. Previously we weren't even using the nice scheduling models. There are a few other tweaks needed here, but this change at least I have benchmarked across a decent swatch of chips (intel's clovertown, westmere, and sandybridge; amd's istanbul) and seen no significant regressions. If anyone has suggested ways to test this, just let me know. Somewhat alarmingly, no existing tests failed. llvm-svn: 208230
2014-05-08 01:37:03 +08:00
// We also provide a generic 64-bit specific x86 processor model which tries to
// be good for modern chips without enabling instruction set encodings past the
// basic SSE2 and 64-bit ones. It disables slow things from any mainstream and
// modern 64-bit x86 chip, and enables features that are generally beneficial.
//
// We currently use the Sandy Bridge model as the default scheduling model as
// we use it across Nehalem, Westmere, Sandy Bridge, and Ivy Bridge which
// covers a huge swath of x86 processors. If there are specific scheduling
// knobs which need to be tuned differently for AMD chips, we might consider
// forming a common base for them.
def : ProcessorModel<"x86-64", SandyBridgeModel,
[FeatureSSE2, Feature64Bit, FeatureSlowBTMem,
FeatureFastUAMem]>;
Initial checkin of X86.td file llvm-svn: 7510
2003-08-03 23:47:49 +08:00
//===----------------------------------------------------------------------===//
// Register File Description
//===----------------------------------------------------------------------===//
include "X86RegisterInfo.td"
Add Target class for X86 target llvm-svn: 7523
2003-08-04 02:19:37 +08:00
//===----------------------------------------------------------------------===//
// Instruction Descriptions
//===----------------------------------------------------------------------===//
Add new TableGen instruction definitions llvm-svn: 7537
2003-08-04 05:54:21 +08:00
include "X86InstrInfo.td"
Replace TSFlagsFields and TSFlagsShifts with a simpler TSFlags field. When a target instruction wants to set target-specific flags, it should simply set bits in the TSFlags bit vector defined in the Instruction TableGen class. This works well because TableGen resolves member references late: class I : Instruction { AddrMode AM = AddrModeNone; let TSFlags{3-0} = AM.Value; } let AM = AddrMode4 in def ADD : I; TSFlags gets the expected bits from AddrMode4 in this example. llvm-svn: 100384
2010-04-05 11:10:20 +08:00
def X86InstrInfo : InstrInfo;
Add Target class for X86 target llvm-svn: 7523
2003-08-04 02:19:37 +08:00
Add a description of the X86-64 calling convention and the return conventions. This doesn't do anything yet, but may in the future. llvm-svn: 34636
2007-02-27 02:17:14 +08:00
//===----------------------------------------------------------------------===//
// Calling Conventions
//===----------------------------------------------------------------------===//
include "X86CallingConv.td"
//===----------------------------------------------------------------------===//
Clean up comments. llvm-svn: 117785
2010-10-30 21:48:28 +08:00
// Assembly Parser
Add a description of the X86-64 calling convention and the return conventions. This doesn't do anything yet, but may in the future. llvm-svn: 34636
2007-02-27 02:17:14 +08:00
//===----------------------------------------------------------------------===//
Match X86 register names to number. llvm-svn: 77404
2009-07-29 08:02:19 +08:00
def ATTAsmParser : AsmParser {
Rename X86ATTAsmParser -> X86AsmParser We are using one parser to parse att as well as intel style syntax. llvm-svn: 148032
2012-01-13 02:03:40 +08:00
string AsmParserClassName = "AsmParser";
Split AsmParser into two components - AsmParser and AsmParserVariant AsmParser holds info specific to target parser. AsmParserVariant holds info specific to asm variants supported by the target. llvm-svn: 147787
2012-01-10 03:13:28 +08:00
}
def ATTAsmParserVariant : AsmParserVariant {
Match X86 register names to number. llvm-svn: 77404
2009-07-29 08:02:19 +08:00
int Variant = 0;
llvm-mc/AsmParser: Allow target to specific a comment delimiter, which will be used to strip hard coded comments out of .td assembly strings. llvm-svn: 78716
2009-08-12 04:59:47 +08:00
[asm parser] Add support for predicating MnemonicAlias based on the assembler variant/dialect. Addresses a FIXME in the emitMnemonicAliases function. Use and test case to come shortly. rdar://13688439 and part of PR13340. llvm-svn: 179804
2013-04-19 06:35:36 +08:00
// Variant name.
string Name = "att";
llvm-mc/AsmParser: Allow target to specific a comment delimiter, which will be used to strip hard coded comments out of .td assembly strings. llvm-svn: 78716
2009-08-12 04:59:47 +08:00
// Discard comments in assembly strings.
string CommentDelimiter = "#";
// Recognize hard coded registers.
string RegisterPrefix = "%";
Match X86 register names to number. llvm-svn: 77404
2009-07-29 08:02:19 +08:00
}
Add definition for intel asm variant. Right now, this just adds additional entries in match table. The parser does not use them yet. llvm-svn: 147859
2012-01-11 01:51:54 +08:00
def IntelAsmParserVariant : AsmParserVariant {
int Variant = 1;
[asm parser] Add support for predicating MnemonicAlias based on the assembler variant/dialect. Addresses a FIXME in the emitMnemonicAliases function. Use and test case to come shortly. rdar://13688439 and part of PR13340. llvm-svn: 179804
2013-04-19 06:35:36 +08:00
// Variant name.
string Name = "intel";
Add definition for intel asm variant. Right now, this just adds additional entries in match table. The parser does not use them yet. llvm-svn: 147859
2012-01-11 01:51:54 +08:00
// Discard comments in assembly strings.
string CommentDelimiter = ";";
// Recognize hard coded registers.
string RegisterPrefix = "";
}
Clean up comments. llvm-svn: 117785
2010-10-30 21:48:28 +08:00
//===----------------------------------------------------------------------===//
// Assembly Printers
//===----------------------------------------------------------------------===//
Add support for the -x86-asm-syntax flag, which can be used to choose between Intel and AT&T style assembly language. The ultimate goal of this is to eliminate the GasBugWorkaroundEmitter class, but for now AT&T style emission is not fully operational. llvm-svn: 16639
2004-10-04 04:36:57 +08:00
// The X86 target supports two different syntaxes for emitting machine code.
// This is controlled by the -x86-asm-syntax={att|intel}
def ATTAsmWriter : AsmWriter {
split MCInst printing out of the X86ATTInstPrinter class into its own X86ATTInstPrinter class. The inst printer now has just one dependence on the code generator (TRI). llvm-svn: 81703
2009-09-14 03:30:11 +08:00
string AsmWriterClassName = "ATTInstPrinter";
Add support for the -x86-asm-syntax flag, which can be used to choose between Intel and AT&T style assembly language. The ultimate goal of this is to eliminate the GasBugWorkaroundEmitter class, but for now AT&T style emission is not fully operational. llvm-svn: 16639
2004-10-04 04:36:57 +08:00
int Variant = 0;
}
def IntelAsmWriter : AsmWriter {
remove a temporary hack. llvm-svn: 82395
2009-09-20 15:47:59 +08:00
string AsmWriterClassName = "IntelInstPrinter";
Add support for the -x86-asm-syntax flag, which can be used to choose between Intel and AT&T style assembly language. The ultimate goal of this is to eliminate the GasBugWorkaroundEmitter class, but for now AT&T style emission is not fully operational. llvm-svn: 16639
2004-10-04 04:36:57 +08:00
int Variant = 1;
}
Add Target class for X86 target llvm-svn: 7523
2003-08-04 02:19:37 +08:00
def X86 : Target {
// Information about the instructions...
transition to using let instead of set llvm-svn: 7564
2003-08-04 12:59:56 +08:00
let InstructionSet = X86InstrInfo;
Match X86 register names to number. llvm-svn: 77404
2009-07-29 08:02:19 +08:00
let AssemblyParsers = [ATTAsmParser];
Add definition for intel asm variant. Right now, this just adds additional entries in match table. The parser does not use them yet. llvm-svn: 147859
2012-01-11 01:51:54 +08:00
let AssemblyParserVariants = [ATTAsmParserVariant, IntelAsmParserVariant];
Add support for the -x86-asm-syntax flag, which can be used to choose between Intel and AT&T style assembly language. The ultimate goal of this is to eliminate the GasBugWorkaroundEmitter class, but for now AT&T style emission is not fully operational. llvm-svn: 16639
2004-10-04 04:36:57 +08:00
let AssemblyWriters = [ATTAsmWriter, IntelAsmWriter];
Add Target class for X86 target llvm-svn: 7523
2003-08-04 02:19:37 +08:00
}