6502/llvm-6502
1
0
Fork 0
mirror of https://github.com/c64scene-ar/llvm-6502.git synced 2024-12-15 20:29:48 +00:00
Code Issues Projects Releases Wiki Activity
4e5aa77b3d
llvm-6502/lib/Target/X86/X86.td

573 lines
28 KiB
TableGen
Raw Normal View History

Emacs-tag and some comment fix for all ARM, CellSPU, Hexagon, MBlaze, MSP430, PPC, PTX, Sparc, X86, XCore. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150878 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-18 12:03:15 +00:00
//===-- X86.td - Target definition file for the Intel X86 --*- tablegen -*-===//
Fix whitespace and tabs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129517 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14 14:33:36 +00:00
//
Added LLVM copyright header. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9321 91177308-0d34-0410-b5e6-96231b3b80d8
2003-10-21 15:17:13 +00:00
// The LLVM Compiler Infrastructure
//
Remove attribution from file headers, per discussion on llvmdev. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@45418 91177308-0d34-0410-b5e6-96231b3b80d8
2007-12-29 20:36:04 +00:00
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
Fix whitespace and tabs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129517 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14 14:33:36 +00:00
//
Added LLVM copyright header. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9321 91177308-0d34-0410-b5e6-96231b3b80d8
2003-10-21 15:17:13 +00:00
//===----------------------------------------------------------------------===//
Initial checkin of X86.td file git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7510 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 15:47:49 +00:00
//
Add X86 LZCNT instruction. Including instruction selection support. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141651 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-11 06:44:02 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7510 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 15:47:49 +00:00
//
//===----------------------------------------------------------------------===//
transition to using let instead of set git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7564 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-04 04:59:56 +00:00
// Get the target-independent interfaces which we are implementing...
Initial checkin of X86.td file git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7510 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 15:47:49 +00:00
//
Move target independent td files from lib/Target/ to include/llvm/Target so they can be distributed along with the header files. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@59953 91177308-0d34-0410-b5e6-96231b3b80d8
2008-11-24 07:34:46 +00:00
include "llvm/Target/Target.td"
Initial checkin of X86.td file git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7510 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 15:47:49 +00:00
Add Mode64Bit feature and sink it down to MC layer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134641 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-07 21:06:52 +00:00
//===----------------------------------------------------------------------===//
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162010 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-16 03:50:04 +00:00
// X86 Subtarget state
Add Mode64Bit feature and sink it down to MC layer. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134641 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-07 21:06:52 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198584 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-06 04:55:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@134641 91177308-0d34-0410-b5e6-96231b3b80d8
2011-07-07 21:06:52 +00:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00:00
//===----------------------------------------------------------------------===//
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162010 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-16 03:50:04 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36756 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-04 20:38:40 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80763 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-02 05:53:04 +00: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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@120917 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-04 20:32:23 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@93151 91177308-0d34-0410-b5e6-96231b3b80d8
2010-01-11 16:29:42 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36756 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-04 20:38:40 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80763 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-02 05:53:04 +00:00
// SSE codegen depends on cmovs, and all
Fix whitespace and tabs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129517 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-14 14:33:36 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80763 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-02 05:53:04 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36756 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-04 20:38:40 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189141 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 20:21:34 +00:00
def FeatureSSE41 : SubtargetFeature<"sse4.1", "X86SSELevel", "SSE41",
SSE 4.1 Intrinsics and detection git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46681 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-03 07:18:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189141 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 20:21:34 +00:00
def FeatureSSE42 : SubtargetFeature<"sse4.2", "X86SSELevel", "SSE42",
SSE 4.1 Intrinsics and detection git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@46681 91177308-0d34-0410-b5e6-96231b3b80d8
2008-02-03 07:18:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147339 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-29 15:51:45 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36756 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-04 20:38:40 +00:00
def Feature3DNow : SubtargetFeature<"3dnow", "X863DNowLevel", "ThreeDNow",
Add 3DNow! intrinsics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129551 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-15 00:32:41 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36756 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-04 20:38:40 +00:00
def Feature3DNowA : SubtargetFeature<"3dnowa", "X863DNowLevel", "ThreeDNowA",
3DNowA implies 3DNow. 64-bit implies SSE1, SSE2, and I assume MMX. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36860 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-06 07:56:19 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63575 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-03 00:04:43 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@36860 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-06 07:56:19 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@98520 91177308-0d34-0410-b5e6-96231b3b80d8
2010-03-14 22:24:34 +00: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? git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192044 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-05 20:11:44 +00:00
def FeatureCMPXCHG16B : SubtargetFeature<"cx16", "HasCmpxchg16b", "true",
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138660 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-26 21:21:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61557 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-02 05:35:45 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
def FeatureSlowSHLD : SubtargetFeature<"slow-shld", "IsSHLDSlow", "true",
"SHLD instruction is slow">;
Enable FeatureFastUAMem for btver2 Allow unaligned 16-byte memop codegen for btver2. No functional changes for any other subtargets. Replace the existing supposed small memcpy test with an actual test of a small memcpy. The previous test wasn't using FileCheck either. This patch should allow us to close PR21541 ( http://llvm.org/bugs/show_bug.cgi?id=21541 ). Differential Revision: http://reviews.llvm.org/D6360 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222925 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-28 18:40:18 +00:00
// FIXME: This is a 16-byte (SSE/AVX) feature; we should rename it to make that
// explicit. Also, it seems this would be the default state for most chips
// going forward, so it would probably be better to negate the logic and
// match the 32-byte "slow mem" feature below.
Nehalem unaligned memory access is fast. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100089 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-01 05:58:17 +00:00
def FeatureFastUAMem : SubtargetFeature<"fast-unaligned-mem",
"IsUAMemFast", "true",
"Fast unaligned memory access">;
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222544 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-21 17:40:04 +00:00
def FeatureSlowUAMem32 : SubtargetFeature<"slow-unaligned-mem-32",
"IsUAMem32Slow", "true",
"Slow unaligned 32-byte 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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@72434 91177308-0d34-0410-b5e6-96231b3b80d8
2009-05-26 21:04:35 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147369 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-30 07:16:00 +00:00
"Support SSE 4a instructions",
[FeatureSSE3]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147770 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-09 09:02:13 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143319 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-30 19:57:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188859 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-21 03:57:57 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187030 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-24 11:02:47 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188859 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-21 03:57:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187324 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-28 08:28:38 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188859 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-21 03:57:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187324 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-28 08:28:38 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@188859 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-21 03:57:57 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187324 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-28 08:28:38 +00: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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213545 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 14:54:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157745 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-31 14:34:17 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155888 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 05:28:32 +00:00
[FeatureSSE2]>;
Rename FMA3 feature flag to just FMA to match gcc so it can be added to clang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157903 91177308-0d34-0410-b5e6-96231b3b80d8
2012-06-03 18:58:46 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147349 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-29 19:46:19 +00:00
"Enable three-operand fused multiple-add",
[FeatureAVX]>;
Add feature flags for AVX and FMA and fix some SSE4A feature flag initialization problems. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74350 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26 22:46:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147369 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-30 07:16:00 +00:00
"Enable four-operand fused multiple-add",
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155897 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 06:54:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147369 91177308-0d34-0410-b5e6-96231b3b80d8
2011-12-30 07:16:00 +00:00
def FeatureXOP : SubtargetFeature<"xop", "HasXOP", "true",
Make XOP imply AVX as its needed to legalize the registers types. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155891 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 05:41:41 +00:00
"Enable XOP instructions",
Patch to enable FMA on bdver2 target. Make XOP feature enable FMA4 as well. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@162012 91177308-0d34-0410-b5e6-96231b3b80d8
2012-08-16 04:04:02 +00:00
[FeatureFMA4]>;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227983 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 17:13:04 +00:00
def FeatureSSEUnalignedMem : SubtargetFeature<"sse-unaligned-mem",
"HasSSEUnalignedMem", "true",
"Allow unaligned memory operands with SSE 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100231 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-02 21:54:27 +00:00
def FeatureAES : SubtargetFeature<"aes", "HasAES", "true",
Make CLMUL and AES imply SSE2 since its needed to legalize the type. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155888 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 05:28:32 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@191324 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-24 18:21:52 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141007 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-03 17:28:23 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@189141 91177308-0d34-0410-b5e6-96231b3b80d8
2013-08-23 20:21:34 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141007 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-03 17:28:23 +00:00
"Support RDRAND instruction">;
Add Ivy Bridge 16-bit floating point conversion instructions for the X86 disassembler. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141505 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-09 07:31:39 +00:00
def FeatureF16C : SubtargetFeature<"f16c", "HasF16C", "true",
Make F16C feature flag imply AVX rather than just checking both at the patterns. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190775 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-16 04:29:58 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@143319 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-30 19:57:21 +00:00
def FeatureFSGSBase : SubtargetFeature<"fsgsbase", "HasFSGSBase", "true",
"Support FS/GS Base instructions">;
Add X86 LZCNT instruction. Including instruction selection support. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141651 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-11 06:44:02 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141939 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-14 03:21:46 +00:00
def FeatureBMI : SubtargetFeature<"bmi", "HasBMI", "true",
"Support BMI instructions">;
Add X86 BZHI instruction as well as BMI2 feature detection. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@142122 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-16 07:55:05 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@167573 91177308-0d34-0410-b5e6-96231b3b80d8
2012-11-08 07:28:54 +00:00
def FeatureRTM : SubtargetFeature<"rtm", "HasRTM", "true",
"Support RTM instructions">;
Add HLE target feature git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178082 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-26 22:46:02 +00:00
def FeatureHLE : SubtargetFeature<"hle", "HasHLE", "true",
"Support HLE">;
added basic support for Intel ADX instructions -feature flag, instructions definitions, test cases git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@175196 91177308-0d34-0410-b5e6-96231b3b80d8
2013-02-14 19:08:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190611 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-12 15:51:31 +00:00
def FeatureSHA : SubtargetFeature<"sha", "HasSHA", "true",
"Enable SHA instructions",
[FeatureSSE2]>;
Add PREFETCHW codegen support - Add 'PRFCHW' feature defined in AVX2 ISA extension git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178040 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-26 17:47:11 +00:00
def FeaturePRFCHW : SubtargetFeature<"prfchw", "HasPRFCHW", "true",
"Support PRFCHW instructions">;
Add support of RDSEED defined in AVX2 extension git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178314 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-28 23:41:26 +00:00
def FeatureRDSEED : SubtargetFeature<"rdseed", "HasRDSEED", "true",
"Support RDSEED instruction">;
Use LEA to adjust stack ptr for Atom. Patch by Andy Zhang. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@150008 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-07 22:50:41 +00:00
def FeatureLeaForSP : SubtargetFeature<"lea-sp", "UseLeaForSP", "true",
"Use LEA for adjusting the stack pointer">;
[X86] For Silvermont CPU use 16-bit division instead of 64-bit for small positive numbers Differential Revision: http://reviews.llvm.org/D5938 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222521 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-21 11:19:34 +00:00
def FeatureSlowDivide32 : SubtargetFeature<"idivl-to-divb",
"HasSlowDivide32", "true",
"Use 8-bit divide for positive values less than 256">;
def FeatureSlowDivide64 : SubtargetFeature<"idivq-to-divw",
"HasSlowDivide64", "true",
"Use 16-bit divide for positive values less than 65536">;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171879 91177308-0d34-0410-b5e6-96231b3b80d8
2013-01-08 18:27:24 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178171 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-27 19:14:02 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@180573 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-25 20:29:37 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@209198 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-20 08:55:50 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@210466 91177308-0d34-0410-b5e6-96231b3b80d8
2014-06-09 11:40:41 +00:00
def FeatureSlowIncDec : SubtargetFeature<"slow-incdec", "SlowIncDec", "true",
"INC and DEC instructions are slower than ADD and SUB">;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@237079 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-12 01:26:05 +00:00
def FeatureSoftFloat
: SubtargetFeature<"soft-float", "UseSoftFloat", "true",
"Use software floating point features.">;
Add feature flags for AVX and FMA and fix some SSE4A feature flag initialization problems. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@74350 91177308-0d34-0410-b5e6-96231b3b80d8
2009-06-26 22:46:54 +00:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00: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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149558 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01 23:20:51 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@190717 91177308-0d34-0410-b5e6-96231b3b80d8
2013-09-13 19:23:28 +00: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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149558 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01 23:20:51 +00:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159891 91177308-0d34-0410-b5e6-96231b3b80d8
2012-07-07 04:00:00 +00: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! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@149558 91177308-0d34-0410-b5e6-96231b3b80d8
2012-02-01 23:20:51 +00:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@57528 91177308-0d34-0410-b5e6-96231b3b80d8
2008-10-14 22:06:33 +00:00
def : Proc<"i586", []>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@80763 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-02 05:53:04 +00:00
def : Proc<"pentiumpro", [FeatureCMOV]>;
def : Proc<"pentium2", [FeatureMMX, FeatureCMOV]>;
We only need to specify the most-implied feature for an architecture. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37275 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-22 05:15:37 +00:00
def : Proc<"pentium3", [FeatureSSE1]>;
Add pentium{3,4}m cpus. Patch by Alexander Best! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130749 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-03 03:42:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@61557 91177308-0d34-0410-b5e6-96231b3b80d8
2009-01-02 05:35:45 +00:00
def : Proc<"pentium-m", [FeatureSSE2, FeatureSlowBTMem]>;
We only need to specify the most-implied feature for an architecture. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37275 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-22 05:15:37 +00:00
def : Proc<"pentium4", [FeatureSSE2]>;
Add pentium{3,4}m cpus. Patch by Alexander Best! git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@130749 91177308-0d34-0410-b5e6-96231b3b80d8
2011-05-03 03:42:50 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208230 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 17:37:03 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178080 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-26 22:19:12 +00: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]>;
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
// Atom CPUs.
class BonnellProc<string Name> : ProcessorModel<Name, AtomModel, [
ProcIntelAtom,
FeatureSSSE3,
FeatureCMPXCHG16B,
FeatureMOVBE,
FeatureSlowBTMem,
FeatureLeaForSP,
FeatureSlowDivide32,
FeatureSlowDivide64,
FeatureCallRegIndirect,
FeatureLEAUsesAG,
FeaturePadShortFunctions
]>;
def : BonnellProc<"bonnell">;
def : BonnellProc<"atom">; // Pin the generic name to the baseline.
class SilvermontProc<string Name> : ProcessorModel<Name, SLMModel, [
ProcIntelSLM,
FeatureSSE42,
FeatureCMPXCHG16B,
FeatureMOVBE,
FeaturePOPCNT,
FeaturePCLMUL,
FeatureAES,
FeatureSlowDivide64,
FeatureCallRegIndirect,
FeaturePRFCHW,
FeatureSlowLEA,
FeatureSlowIncDec,
FeatureSlowBTMem,
FeatureFastUAMem
]>;
def : SilvermontProc<"silvermont">;
def : SilvermontProc<"slm">; // Legacy alias.
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178080 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-26 22:19:12 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100231 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-02 21:54:27 +00:00
// "Arrandale" along with corei3 and corei5
[X86] Remove FeatureAES for 'corei7' CPU. 'corei7' should match 'nehalem' which doesn't have AES. Having AES and not PCLMUL makes 'corei7' halfway between Nehalem and Westmere. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@233517 91177308-0d34-0410-b5e6-96231b3b80d8
2015-03-30 06:31:11 +00:00
class NehalemProc<string Name> : ProcessorModel<Name, SandyBridgeModel, [
FeatureSSE42,
FeatureCMPXCHG16B,
FeatureSlowBTMem,
FeatureFastUAMem,
FeaturePOPCNT
]>;
def : NehalemProc<"nehalem">;
def : NehalemProc<"corei7">;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@178080 91177308-0d34-0410-b5e6-96231b3b80d8
2013-03-26 22:19:12 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100231 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-02 21:54:27 +00:00
// Westmere is a similar machine to nehalem with some additional features.
// Westmere is the corei3/i5/i7 path from nehalem to sandybridge
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
class WestmereProc<string Name> : ProcessorModel<Name, SandyBridgeModel, [
FeatureSSE42,
FeatureCMPXCHG16B,
FeatureSlowBTMem,
FeatureFastUAMem,
FeaturePOPCNT,
FeatureAES,
FeaturePCLMUL
]>;
def : WestmereProc<"westmere">;
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@121439 91177308-0d34-0410-b5e6-96231b3b80d8
2010-12-10 00:26:57 +00:00
// SSE is not listed here since llvm treats AVX as a reimplementation of SSE,
// rather than a superset.
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
class SandyBridgeProc<string Name> : ProcessorModel<Name, SandyBridgeModel, [
FeatureAVX,
FeatureCMPXCHG16B,
FeatureFastUAMem,
FeatureSlowUAMem32,
FeaturePOPCNT,
FeatureAES,
FeaturePCLMUL
]>;
def : SandyBridgeProc<"sandybridge">;
def : SandyBridgeProc<"corei7-avx">; // Legacy alias.
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00:00
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
class IvyBridgeProc<string Name> : ProcessorModel<Name, SandyBridgeModel, [
FeatureAVX,
FeatureCMPXCHG16B,
FeatureFastUAMem,
FeatureSlowUAMem32,
FeaturePOPCNT,
FeatureAES,
FeaturePCLMUL,
FeatureRDRAND,
FeatureF16C,
FeatureFSGSBase
]>;
def : IvyBridgeProc<"ivybridge">;
def : IvyBridgeProc<"core-avx-i">; // Legacy alias.
class HaswellProc<string Name> : ProcessorModel<Name, HaswellModel, [
FeatureAVX2,
FeatureCMPXCHG16B,
FeatureFastUAMem,
FeaturePOPCNT,
FeatureAES,
FeaturePCLMUL,
FeatureRDRAND,
FeatureF16C,
FeatureFSGSBase,
FeatureMOVBE,
FeatureLZCNT,
FeatureBMI,
FeatureBMI2,
FeatureFMA,
FeatureRTM,
FeatureHLE,
FeatureSlowIncDec
]>;
def : HaswellProc<"haswell">;
def : HaswellProc<"core-avx2">; // Legacy alias.
class BroadwellProc<string Name> : ProcessorModel<Name, HaswellModel, [
FeatureAVX2,
FeatureCMPXCHG16B,
FeatureFastUAMem,
FeaturePOPCNT,
FeatureAES,
FeaturePCLMUL,
FeatureRDRAND,
FeatureF16C,
FeatureFSGSBase,
FeatureMOVBE,
FeatureLZCNT,
FeatureBMI,
FeatureBMI2,
FeatureFMA,
FeatureRTM,
FeatureHLE,
FeatureADX,
FeatureRDSEED,
FeatureSlowIncDec
]>;
def : BroadwellProc<"broadwell">;
Add X86 TZCNT instruction and patterns to select it. Also added core-avx2 processor which is gcc's name for Haswell. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@141939 91177308-0d34-0410-b5e6-96231b3b80d8
2011-10-14 03:21:46 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187030 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-24 11:02:47 +00:00
// FIXME: define KNL model
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
class KnightsLandingProc<string Name> : ProcessorModel<Name, HaswellModel,
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187030 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-24 11:02:47 +00:00
[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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@212178 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-02 14:11:05 +00:00
FeatureBMI2, FeatureFMA, FeatureRTM, FeatureHLE,
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@227983 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-03 17:13:04 +00:00
FeatureSlowIncDec]>;
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
def : KnightsLandingProc<"knl">;
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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@187030 91177308-0d34-0410-b5e6-96231b3b80d8
2013-07-24 11:02:47 +00: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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213545 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 14:54:21 +00:00
// FIXME: define SKX model
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
class SkylakeProc<string Name> : ProcessorModel<Name, HaswellModel,
[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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213545 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 14:54:21 +00:00
[FeatureAVX512, FeatureCDI,
FeatureDQI, FeatureBWI, FeatureVLX,
FeatureCMPXCHG16B, FeatureFastUAMem, FeaturePOPCNT,
FeatureAES, FeaturePCLMUL, FeatureRDRAND, FeatureF16C,
FeatureFSGSBase, FeatureMOVBE, FeatureLZCNT, FeatureBMI,
FeatureBMI2, FeatureFMA, FeatureRTM, FeatureHLE,
[X86] Remove two feature flags that covered sets of instructions that have no patterns or intrinsics. Since we don't check feature flags in the assembler parser for any instruction sets, these flags don't provide any value. This frees up 2 of the fully utilized feature flags. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@228282 91177308-0d34-0410-b5e6-96231b3b80d8
2015-02-05 08:51:02 +00:00
FeatureSlowIncDec]>;
[x86] Bring some sanity to the x86 CPU processor definitions. Notably, this adds simple micro-architecture names for the Intel CPU variants, and defines the old 'core'-based names as aliases. GCC has started to simplify their documented interface to use these names as well, so it seems like we can start to converge on a consistent pattern. I'd appreciate Intel double checking the entries that aren't yet documented widely, especially Atom (Bonnell and Silvermont), Knights Landing, and Skylake. But this change shouldn't break any existing users. Also, ran clang-format to re-format this code and it actually worked (modulo a tiny bug) so hopefully we can start to stop thinking about formatting this stuff. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223769 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 10:58:36 +00:00
def : SkylakeProc<"skylake">;
def : SkylakeProc<"skx">; // Legacy alias.
// AMD CPUs.
[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> git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@213545 91177308-0d34-0410-b5e6-96231b3b80d8
2014-07-21 14:54:21 +00:00
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00:00
def : Proc<"k6", [FeatureMMX]>;
Add 3DNow! intrinsics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129551 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-15 00:32:41 +00:00
def : Proc<"k6-2", [Feature3DNow]>;
def : Proc<"k6-3", [Feature3DNow]>;
Test commit Removed whitespace git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@203216 91177308-0d34-0410-b5e6-96231b3b80d8
2014-03-07 08:28:44 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeatureSlowSHLD]>;
def : Proc<"athlon-tbird", [Feature3DNowA, FeatureSlowBTMem,
FeatureSlowSHLD]>;
[X86] Clean up whitespace as well as minor coding style git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223339 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-04 05:20:33 +00:00
def : Proc<"athlon-4", [FeatureSSE1, 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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63575 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-03 00:04:43 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63575 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-03 00:04:43 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63575 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-03 00:04:43 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@63575 91177308-0d34-0410-b5e6-96231b3b80d8
2009-02-03 00:04:43 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeatureSlowBTMem, FeatureSlowSHLD]>;
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138660 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-26 21:21:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeatureSlowBTMem, FeatureSlowSHLD]>;
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138660 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-26 21:21:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeatureSlowBTMem, FeatureSlowSHLD]>;
Add support for generating CMPXCHG16B on x86-64 for the cmpxchg IR instruction. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@138660 91177308-0d34-0410-b5e6-96231b3b80d8
2011-08-26 21:21:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeatureSlowBTMem, FeatureSlowSHLD]>;
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155897 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 06:54:48 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@145494 91177308-0d34-0410-b5e6-96231b3b80d8
2011-11-30 15:48:16 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeaturePOPCNT, FeatureSlowBTMem,
FeatureSlowSHLD]>;
[x86] Fix the test to actually test things for the CPU names, add the missing barcelona CPU which that test uncovered, and remove the 32-bit x86 CPUs which I really wasn't prepared to audit and test thoroughly. If anyone wants to clean up the 32-bit only x86 CPUs, go for it. Also, if anyone else wants to try to de-duplicate the AMD CPUs, that'd be cool, but from the looks of it wouldn't save as much as it did for the Intel CPUs. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223774 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-09 14:25:55 +00:00
def : Proc<"barcelona", [FeatureSSE4A,
Feature3DNowA, FeatureCMPXCHG16B, FeatureLZCNT,
FeaturePOPCNT, FeatureSlowBTMem,
FeatureSlowSHLD]>;
Add definitions for AMD's bobcat (aka btver1) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147846 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-10 11:50:02 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195383 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-21 23:21:26 +00:00
FeaturePRFCHW, FeatureLZCNT, FeaturePOPCNT,
FeatureSlowSHLD]>;
Add a scheduling model for AMD 16H Jaguar (btver2). This is a first pass at a scheduling model for Jaguar. It's structured largely on the existing SandyBridge and SLM sched models. Using this model, in addition to turning on the PostRA scheduler, results in some perf wins on internal and 3rd party benchmarks. There's not much difference in LLVM's test-suite benchmarking subset of tests. Differential Revision: http://reviews.llvm.org/D5229 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217457 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-09 20:07:07 +00:00
X86: Add target description for btver2; make autodetection logic aware of AVX. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181005 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-03 10:20:08 +00:00
// Jaguar
Add a scheduling model for AMD 16H Jaguar (btver2). This is a first pass at a scheduling model for Jaguar. It's structured largely on the existing SandyBridge and SLM sched models. Using this model, in addition to turning on the PostRA scheduler, results in some perf wins on internal and 3rd party benchmarks. There's not much difference in LLVM's test-suite benchmarking subset of tests. Differential Revision: http://reviews.llvm.org/D5229 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217457 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-09 20:07:07 +00:00
def : ProcessorModel<"btver2", BtVer2Model,
[FeatureAVX, FeatureSSE4A, FeatureCMPXCHG16B,
FeaturePRFCHW, FeatureAES, FeaturePCLMUL,
FeatureBMI, FeatureF16C, FeatureMOVBE,
Enable FeatureFastUAMem for btver2 Allow unaligned 16-byte memop codegen for btver2. No functional changes for any other subtargets. Replace the existing supposed small memcpy test with an actual test of a small memcpy. The previous test wasn't using FileCheck either. This patch should allow us to close PR21541 ( http://llvm.org/bugs/show_bug.cgi?id=21541 ). Differential Revision: http://reviews.llvm.org/D6360 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222925 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-28 18:40:18 +00:00
FeatureLZCNT, FeaturePOPCNT, FeatureFastUAMem,
make reciprocal estimate code generation more flexible by adding command-line options This patch adds a class for processing many recip codegen possibilities. The TargetRecip class is intended to handle both command-line options to llc as well as options passed in from a front-end such as clang with the -mrecip option. The x86 backend is updated to use the new functionality. Only -mcpu=btver2 with -ffast-math should see a functional change from this patch. All other CPUs continue to *not* use reciprocal estimates by default with -ffast-math. Differential Revision: http://reviews.llvm.org/D8982 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@238051 91177308-0d34-0410-b5e6-96231b3b80d8
2015-05-22 21:10:06 +00:00
FeatureSlowSHLD]>;
Enable FeatureFastUAMem for btver2 Allow unaligned 16-byte memop codegen for btver2. No functional changes for any other subtargets. Replace the existing supposed small memcpy test with an actual test of a small memcpy. The previous test wasn't using FileCheck either. This patch should allow us to close PR21541 ( http://llvm.org/bugs/show_bug.cgi?id=21541 ). Differential Revision: http://reviews.llvm.org/D6360 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@222925 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-28 18:40:18 +00:00
// TODO: We should probably add 'FeatureFastUAMem' to all of the AMD chips.
Add a scheduling model for AMD 16H Jaguar (btver2). This is a first pass at a scheduling model for Jaguar. It's structured largely on the existing SandyBridge and SLM sched models. Using this model, in addition to turning on the PostRA scheduler, results in some perf wins on internal and 3rd party benchmarks. There's not much difference in LLVM's test-suite benchmarking subset of tests. Differential Revision: http://reviews.llvm.org/D5229 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@217457 91177308-0d34-0410-b5e6-96231b3b80d8
2014-09-09 20:07:07 +00:00
Add definitions for AMD's bobcat (aka btver1) git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147846 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-10 11:50:02 +00:00
// Bulldozer
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155897 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 06:54:48 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192828 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-16 19:04:11 +00:00
FeatureAES, FeaturePRFCHW, FeaturePCLMUL,
[X86] Add 'FeatureSlowSHLD' to cpu 'bdver3'. Also explicit set FeatureAVX and FeatureSSE4A for all the bdver* cpus. This patch adds 'FeatureSlowSHLD' to 'bdver3'. According to the official AMD optimization guide for amdfam15: "Using alternative code in place of SHLD achieves lower overall latency and requires fewer execution resources. The 32-bit and 64-bit forms of ADD, ADC, SHR, and LEA (except 16-bit form) are DirectPath instructions, while SHLD is a VectorPath instruction." This patch also explicitly sets feature AVX and SSE4A for all the bdver* cpus. This part of the patch is a non-functional change and it is mainly done for clarity reasons (Both XOP and FMA4 already imply AVX and SSE4A). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221296 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-04 21:18:09 +00:00
FeatureAVX, FeatureSSE4A, FeatureLZCNT,
FeaturePOPCNT, FeatureSlowSHLD]>;
X86: Add target description for btver2; make autodetection logic aware of AVX. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@181005 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-03 10:20:08 +00:00
// Piledriver
Make XOP and FMA4 require SSE4A to match GCC behavior. Use this to simplify Bulldozer feature list. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155897 91177308-0d34-0410-b5e6-96231b3b80d8
2012-05-01 06:54:48 +00: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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@192828 91177308-0d34-0410-b5e6-96231b3b80d8
2013-10-16 19:04:11 +00:00
FeatureAES, FeaturePRFCHW, FeaturePCLMUL,
[X86] Add 'FeatureSlowSHLD' to cpu 'bdver3'. Also explicit set FeatureAVX and FeatureSSE4A for all the bdver* cpus. This patch adds 'FeatureSlowSHLD' to 'bdver3'. According to the official AMD optimization guide for amdfam15: "Using alternative code in place of SHLD achieves lower overall latency and requires fewer execution resources. The 32-bit and 64-bit forms of ADD, ADC, SHR, and LEA (except 16-bit form) are DirectPath instructions, while SHLD is a VectorPath instruction." This patch also explicitly sets feature AVX and SSE4A for all the bdver* cpus. This part of the patch is a non-functional change and it is mainly done for clarity reasons (Both XOP and FMA4 already imply AVX and SSE4A). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221296 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-04 21:18:09 +00:00
FeatureAVX, FeatureSSE4A, FeatureF16C,
FeatureLZCNT, FeaturePOPCNT, FeatureBMI,
FeatureTBM, FeatureFMA, FeatureSlowSHLD]>;
X86: Add a description for AMD bdver3 aka Steamroller. This is just bdver2 + FSGSBase. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193984 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-04 10:29:20 +00:00
// Steamroller
def : Proc<"bdver3", [FeatureXOP, FeatureFMA4, FeatureCMPXCHG16B,
FeatureAES, FeaturePRFCHW, FeaturePCLMUL,
[X86] Add 'FeatureSlowSHLD' to cpu 'bdver3'. Also explicit set FeatureAVX and FeatureSSE4A for all the bdver* cpus. This patch adds 'FeatureSlowSHLD' to 'bdver3'. According to the official AMD optimization guide for amdfam15: "Using alternative code in place of SHLD achieves lower overall latency and requires fewer execution resources. The 32-bit and 64-bit forms of ADD, ADC, SHR, and LEA (except 16-bit form) are DirectPath instructions, while SHLD is a VectorPath instruction." This patch also explicitly sets feature AVX and SSE4A for all the bdver* cpus. This part of the patch is a non-functional change and it is mainly done for clarity reasons (Both XOP and FMA4 already imply AVX and SSE4A). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221296 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-04 21:18:09 +00:00
FeatureAVX, FeatureSSE4A, FeatureF16C,
FeatureLZCNT, FeaturePOPCNT, FeatureBMI,
FeatureTBM, FeatureFMA, FeatureSlowSHLD,
FeatureFSGSBase]>;
X86: Add a description for AMD bdver3 aka Steamroller. This is just bdver2 + FSGSBase. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@193984 91177308-0d34-0410-b5e6-96231b3b80d8
2013-11-04 10:29:20 +00:00
Add a description for AMD's bdver4 (aka Excavator). This is just bdver3 + AVX2 + BMI2. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207847 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-02 15:47:07 +00:00
// Excavator
def : Proc<"bdver4", [FeatureAVX2, FeatureXOP, FeatureFMA4,
FeatureCMPXCHG16B, FeatureAES, FeaturePRFCHW,
FeaturePCLMUL, FeatureF16C, FeatureLZCNT,
FeaturePOPCNT, FeatureBMI, FeatureBMI2,
[X86] Add 'FeatureSlowSHLD' to cpu 'bdver3'. Also explicit set FeatureAVX and FeatureSSE4A for all the bdver* cpus. This patch adds 'FeatureSlowSHLD' to 'bdver3'. According to the official AMD optimization guide for amdfam15: "Using alternative code in place of SHLD achieves lower overall latency and requires fewer execution resources. The 32-bit and 64-bit forms of ADD, ADC, SHR, and LEA (except 16-bit form) are DirectPath instructions, while SHLD is a VectorPath instruction." This patch also explicitly sets feature AVX and SSE4A for all the bdver* cpus. This part of the patch is a non-functional change and it is mainly done for clarity reasons (Both XOP and FMA4 already imply AVX and SSE4A). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@221296 91177308-0d34-0410-b5e6-96231b3b80d8
2014-11-04 21:18:09 +00:00
FeatureTBM, FeatureFMA, FeatureSSE4A,
FeatureFSGSBase]>;
Add a description for AMD's bdver4 (aka Excavator). This is just bdver3 + AVX2 + BMI2. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@207847 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-02 15:47:07 +00:00
Add support for AMD Geode. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@163710 91177308-0d34-0410-b5e6-96231b3b80d8
2012-09-12 14:36:02 +00:00
def : Proc<"geode", [Feature3DNowA]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00:00
def : Proc<"winchip-c6", [FeatureMMX]>;
Add 3DNow! intrinsics. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@129551 91177308-0d34-0410-b5e6-96231b3b80d8
2011-04-15 00:32:41 +00:00
def : Proc<"winchip2", [Feature3DNow]>;
def : Proc<"c3", [Feature3DNow]>;
We only need to specify the most-implied feature for an architecture. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@37275 91177308-0d34-0410-b5e6-96231b3b80d8
2007-05-22 05:15:37 +00:00
def : Proc<"c3-2", [FeatureSSE1]>;
Still need to support -mcpu=<> or cross compilation will fail. Doh. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@30764 91177308-0d34-0410-b5e6-96231b3b80d8
2006-10-06 09:17:41 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208230 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 17:37:03 +00: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.
[X86] Clean up whitespace as well as minor coding style git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@223339 91177308-0d34-0410-b5e6-96231b3b80d8
2014-12-04 05:20:33 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@208230 91177308-0d34-0410-b5e6-96231b3b80d8
2014-05-07 17:37:03 +00:00
// 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 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7510 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 15:47:49 +00:00
//===----------------------------------------------------------------------===//
// Register File Description
//===----------------------------------------------------------------------===//
include "X86RegisterInfo.td"
Add Target class for X86 target git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7523 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 18:19:37 +00:00
//===----------------------------------------------------------------------===//
// Instruction Descriptions
//===----------------------------------------------------------------------===//
Add new TableGen instruction definitions git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7537 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 21:54:21 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@100384 91177308-0d34-0410-b5e6-96231b3b80d8
2010-04-05 03:10:20 +00:00
def X86InstrInfo : InstrInfo;
Add Target class for X86 target git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7523 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 18:19:37 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34636 91177308-0d34-0410-b5e6-96231b3b80d8
2007-02-26 18:17:14 +00:00
//===----------------------------------------------------------------------===//
// Calling Conventions
//===----------------------------------------------------------------------===//
include "X86CallingConv.td"
//===----------------------------------------------------------------------===//
Clean up comments. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117785 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-30 13:48:28 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@34636 91177308-0d34-0410-b5e6-96231b3b80d8
2007-02-26 18:17:14 +00:00
//===----------------------------------------------------------------------===//
Match X86 register names to number. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77404 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-29 00:02:19 +00:00
def ATTAsmParser : AsmParser {
Rename X86ATTAsmParser -> X86AsmParser We are using one parser to parse att as well as intel style syntax. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@148032 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-12 18:03:40 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147787 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-09 19:13:28 +00:00
}
def ATTAsmParserVariant : AsmParserVariant {
Match X86 register names to number. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77404 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-29 00:02:19 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78716 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-11 20:59:47 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179804 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 22:35:36 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@78716 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-11 20:59:47 +00:00
// Discard comments in assembly strings.
string CommentDelimiter = "#";
// Recognize hard coded registers.
string RegisterPrefix = "%";
Match X86 register names to number. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77404 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-29 00:02:19 +00:00
}
Add definition for intel asm variant. Right now, this just adds additional entries in match table. The parser does not use them yet. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147859 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-10 17:51:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@179804 91177308-0d34-0410-b5e6-96231b3b80d8
2013-04-18 22:35:36 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147859 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-10 17:51:54 +00:00
// Discard comments in assembly strings.
string CommentDelimiter = ";";
// Recognize hard coded registers.
string RegisterPrefix = "";
}
Clean up comments. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@117785 91177308-0d34-0410-b5e6-96231b3b80d8
2010-10-30 13:48:28 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16639 91177308-0d34-0410-b5e6-96231b3b80d8
2004-10-03 20:36:57 +00: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). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@81703 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-13 19:30:11 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16639 91177308-0d34-0410-b5e6-96231b3b80d8
2004-10-03 20:36:57 +00:00
int Variant = 0;
}
def IntelAsmWriter : AsmWriter {
remove a temporary hack. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@82395 91177308-0d34-0410-b5e6-96231b3b80d8
2009-09-20 07:47:59 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16639 91177308-0d34-0410-b5e6-96231b3b80d8
2004-10-03 20:36:57 +00:00
int Variant = 1;
}
Add Target class for X86 target git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7523 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 18:19:37 +00:00
def X86 : Target {
// Information about the instructions...
transition to using let instead of set git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7564 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-04 04:59:56 +00:00
let InstructionSet = X86InstrInfo;
Match X86 register names to number. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@77404 91177308-0d34-0410-b5e6-96231b3b80d8
2009-07-29 00:02:19 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@147859 91177308-0d34-0410-b5e6-96231b3b80d8
2012-01-10 17:51:54 +00: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. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@16639 91177308-0d34-0410-b5e6-96231b3b80d8
2004-10-03 20:36:57 +00:00
let AssemblyWriters = [ATTAsmWriter, IntelAsmWriter];
Add Target class for X86 target git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@7523 91177308-0d34-0410-b5e6-96231b3b80d8
2003-08-03 18:19:37 +00:00
}
Reference in New Issue Copy Permalink