2012-02-18 20:03:15 +08:00
|
|
|
//===-- X86.td - Target definition file for the Intel X86 --*- tablegen -*-===//
|
2011-04-14 22:33:36 +08:00
|
|
|
//
|
2003-10-21 23:17:13 +08:00
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
2007-12-30 04:36:04 +08:00
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
2011-04-14 22:33:36 +08:00
|
|
|
//
|
2003-10-21 23:17:13 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2003-08-03 23:47:49 +08:00
|
|
|
//
|
2011-10-11 14:44:02 +08:00
|
|
|
// This is a target description file for the Intel i386 architecture, referred
|
|
|
|
|
// to here as the "X86" architecture.
|
2003-08-03 23:47:49 +08:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2003-08-04 12:59:56 +08:00
|
|
|
// Get the target-independent interfaces which we are implementing...
|
2003-08-03 23:47:49 +08:00
|
|
|
//
|
2008-11-24 15:34:46 +08:00
|
|
|
include "llvm/Target/Target.td"
|
2003-08-03 23:47:49 +08:00
|
|
|
|
2011-07-08 05:06:52 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2012-08-16 11:50:04 +08:00
|
|
|
// X86 Subtarget state
|
2011-07-08 05:06:52 +08:00
|
|
|
//
|
|
|
|
|
|
|
|
|
|
def Mode64Bit : SubtargetFeature<"64bit-mode", "In64BitMode", "true",
|
|
|
|
|
"64-bit mode (x86_64)">;
|
2014-01-06 12:55:54 +08:00
|
|
|
def Mode32Bit : SubtargetFeature<"32bit-mode", "In32BitMode", "true",
|
|
|
|
|
"32-bit mode (80386)">;
|
|
|
|
|
def Mode16Bit : SubtargetFeature<"16bit-mode", "In16BitMode", "true",
|
|
|
|
|
"16-bit mode (i8086)">;
|
2011-07-08 05:06:52 +08:00
|
|
|
|
2006-10-06 17:17:41 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2012-08-16 11:50:04 +08:00
|
|
|
// X86 Subtarget features
|
2007-05-05 04:38:40 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2009-09-02 13:53:04 +08:00
|
|
|
|
2016-03-23 19:13:54 +08:00
|
|
|
def FeatureX87 : SubtargetFeature<"x87","HasX87", "true",
|
|
|
|
|
"Enable X87 float instructions">;
|
|
|
|
|
|
2018-01-11 06:07:16 +08:00
|
|
|
def FeatureNOPL : SubtargetFeature<"nopl", "HasNOPL", "true",
|
|
|
|
|
"Enable NOPL instruction">;
|
|
|
|
|
|
2009-09-02 13:53:04 +08:00
|
|
|
def FeatureCMOV : SubtargetFeature<"cmov","HasCMov", "true",
|
|
|
|
|
"Enable conditional move instructions">;
|
|
|
|
|
|
2010-12-05 04:32:23 +08:00
|
|
|
def FeaturePOPCNT : SubtargetFeature<"popcnt", "HasPOPCNT", "true",
|
|
|
|
|
"Support POPCNT instruction">;
|
|
|
|
|
|
2015-10-16 14:03:09 +08:00
|
|
|
def FeatureFXSR : SubtargetFeature<"fxsr", "HasFXSR", "true",
|
|
|
|
|
"Support fxsave/fxrestore instructions">;
|
|
|
|
|
|
2015-10-12 19:47:46 +08:00
|
|
|
def FeatureXSAVE : SubtargetFeature<"xsave", "HasXSAVE", "true",
|
|
|
|
|
"Support xsave instructions">;
|
|
|
|
|
|
|
|
|
|
def FeatureXSAVEOPT: SubtargetFeature<"xsaveopt", "HasXSAVEOPT", "true",
|
|
|
|
|
"Support xsaveopt instructions">;
|
|
|
|
|
|
|
|
|
|
def FeatureXSAVEC : SubtargetFeature<"xsavec", "HasXSAVEC", "true",
|
|
|
|
|
"Support xsavec instructions">;
|
|
|
|
|
|
|
|
|
|
def FeatureXSAVES : SubtargetFeature<"xsaves", "HasXSAVES", "true",
|
|
|
|
|
"Support xsaves instructions">;
|
|
|
|
|
|
2007-05-05 04:38:40 +08:00
|
|
|
def FeatureSSE1 : SubtargetFeature<"sse", "X86SSELevel", "SSE1",
|
2018-08-27 02:29:33 +08:00
|
|
|
"Enable SSE instructions">;
|
2007-05-05 04:38:40 +08:00
|
|
|
def FeatureSSE2 : SubtargetFeature<"sse2", "X86SSELevel", "SSE2",
|
|
|
|
|
"Enable SSE2 instructions",
|
|
|
|
|
[FeatureSSE1]>;
|
|
|
|
|
def FeatureSSE3 : SubtargetFeature<"sse3", "X86SSELevel", "SSE3",
|
|
|
|
|
"Enable SSE3 instructions",
|
|
|
|
|
[FeatureSSE2]>;
|
|
|
|
|
def FeatureSSSE3 : SubtargetFeature<"ssse3", "X86SSELevel", "SSSE3",
|
|
|
|
|
"Enable SSSE3 instructions",
|
|
|
|
|
[FeatureSSE3]>;
|
2013-08-24 04:21:34 +08:00
|
|
|
def FeatureSSE41 : SubtargetFeature<"sse4.1", "X86SSELevel", "SSE41",
|
2008-02-03 15:18:54 +08:00
|
|
|
"Enable SSE 4.1 instructions",
|
|
|
|
|
[FeatureSSSE3]>;
|
2013-08-24 04:21:34 +08:00
|
|
|
def FeatureSSE42 : SubtargetFeature<"sse4.2", "X86SSELevel", "SSE42",
|
2008-02-03 15:18:54 +08:00
|
|
|
"Enable SSE 4.2 instructions",
|
2011-12-29 23:51:45 +08:00
|
|
|
[FeatureSSE41]>;
|
2015-11-14 11:04:00 +08:00
|
|
|
// The MMX subtarget feature is separate from the rest of the SSE features
|
|
|
|
|
// because it's important (for odd compatibility reasons) to be able to
|
|
|
|
|
// turn it off explicitly while allowing SSE+ to be on.
|
|
|
|
|
def FeatureMMX : SubtargetFeature<"mmx","X863DNowLevel", "MMX",
|
|
|
|
|
"Enable MMX instructions">;
|
2007-05-05 04:38:40 +08:00
|
|
|
def Feature3DNow : SubtargetFeature<"3dnow", "X863DNowLevel", "ThreeDNow",
|
2011-04-15 08:32:41 +08:00
|
|
|
"Enable 3DNow! instructions",
|
|
|
|
|
[FeatureMMX]>;
|
2007-05-05 04:38:40 +08:00
|
|
|
def Feature3DNowA : SubtargetFeature<"3dnowa", "X863DNowLevel", "ThreeDNowA",
|
2007-05-06 15:56:19 +08:00
|
|
|
"Enable 3DNow! Athlon instructions",
|
|
|
|
|
[Feature3DNow]>;
|
2009-02-03 08:04:43 +08:00
|
|
|
// All x86-64 hardware has SSE2, but we don't mark SSE2 as an implied
|
|
|
|
|
// feature, because SSE2 can be disabled (e.g. for compiling OS kernels)
|
2018-08-30 14:01:05 +08:00
|
|
|
// without disabling 64-bit mode. Nothing should imply this feature bit. It
|
|
|
|
|
// is used to enforce that only 64-bit capable CPUs are used in 64-bit mode.
|
2007-05-06 15:56:19 +08:00
|
|
|
def Feature64Bit : SubtargetFeature<"64bit", "HasX86_64", "true",
|
2018-08-27 02:29:33 +08:00
|
|
|
"Support 64-bit instructions">;
|
2013-10-06 04:11:44 +08:00
|
|
|
def FeatureCMPXCHG16B : SubtargetFeature<"cx16", "HasCmpxchg16b", "true",
|
2018-08-30 14:01:05 +08:00
|
|
|
"64-bit with cmpxchg16b">;
|
SHLD/SHRD are VectorPath (microcode) instructions known to have poor latency on certain architectures. While generating SHLD/SHRD instructions is acceptable when optimizing for size, optimizing for speed on these platforms should be implemented using alternative sequences of instructions composed of add, adc, shr, shl, or and lea which are directPath instructions. These alternative instructions not only have a lower latency but they also increase the decode bandwidth by allowing simultaneous decoding of a third directPath instruction.
AMD's processors family K7, K8, K10, K12, K15 and K16 are known to have SHLD/SHRD instructions with very poor latency. Optimization guides for these processors recommend using an alternative sequence of instructions. For these AMD's processors, I disabled folding (or (x << c) | (y >> (64 - c))) when we are not optimizing for size.
It might be beneficial to disable this folding for some of the Intel's processors. However, since I couldn't find specific recommendations regarding using SHLD/SHRD instructions on Intel's processors, I haven't disabled this peephole for Intel.
llvm-svn: 195383
2013-11-22 07:21:26 +08:00
|
|
|
def FeatureSlowSHLD : SubtargetFeature<"slow-shld", "IsSHLDSlow", "true",
|
|
|
|
|
"SHLD instruction is slow">;
|
2016-12-07 03:35:20 +08:00
|
|
|
def FeatureSlowPMULLD : SubtargetFeature<"slow-pmulld", "IsPMULLDSlow", "true",
|
|
|
|
|
"PMULLD instruction is slow">;
|
2015-09-02 04:51:51 +08:00
|
|
|
// FIXME: This should not apply to CPUs that do not have SSE.
|
|
|
|
|
def FeatureSlowUAMem16 : SubtargetFeature<"slow-unaligned-mem-16",
|
|
|
|
|
"IsUAMem16Slow", "true",
|
|
|
|
|
"Slow unaligned 16-byte memory access">;
|
2014-11-22 01:40:04 +08:00
|
|
|
def FeatureSlowUAMem32 : SubtargetFeature<"slow-unaligned-mem-32",
|
2015-08-22 04:17:26 +08:00
|
|
|
"IsUAMem32Slow", "true",
|
|
|
|
|
"Slow unaligned 32-byte memory access">;
|
2009-05-27 05:04:35 +08:00
|
|
|
def FeatureSSE4A : SubtargetFeature<"sse4a", "HasSSE4A", "true",
|
2011-12-30 15:16:00 +08:00
|
|
|
"Support SSE 4a instructions",
|
|
|
|
|
[FeatureSSE3]>;
|
2006-10-06 17:17:41 +08:00
|
|
|
|
2012-01-09 17:02:13 +08:00
|
|
|
def FeatureAVX : SubtargetFeature<"avx", "X86SSELevel", "AVX",
|
|
|
|
|
"Enable AVX instructions",
|
|
|
|
|
[FeatureSSE42]>;
|
|
|
|
|
def FeatureAVX2 : SubtargetFeature<"avx2", "X86SSELevel", "AVX2",
|
2011-10-31 03:57:21 +08:00
|
|
|
"Enable AVX2 instructions",
|
|
|
|
|
[FeatureAVX]>;
|
2017-11-07 06:49:01 +08:00
|
|
|
def FeatureFMA : SubtargetFeature<"fma", "HasFMA", "true",
|
|
|
|
|
"Enable three-operand fused multiple-add",
|
|
|
|
|
[FeatureAVX]>;
|
2017-11-07 06:49:04 +08:00
|
|
|
def FeatureF16C : SubtargetFeature<"f16c", "HasF16C", "true",
|
|
|
|
|
"Support 16-bit floating point conversion instructions",
|
|
|
|
|
[FeatureAVX]>;
|
2013-08-21 11:57:57 +08:00
|
|
|
def FeatureAVX512 : SubtargetFeature<"avx512f", "X86SSELevel", "AVX512F",
|
2013-07-24 19:02:47 +08:00
|
|
|
"Enable AVX-512 instructions",
|
2017-11-07 06:49:04 +08:00
|
|
|
[FeatureAVX2, FeatureFMA, FeatureF16C]>;
|
2013-08-21 11:57:57 +08:00
|
|
|
def FeatureERI : SubtargetFeature<"avx512er", "HasERI", "true",
|
2013-07-28 16:28:38 +08:00
|
|
|
"Enable AVX-512 Exponential and Reciprocal Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
2013-08-21 11:57:57 +08:00
|
|
|
def FeatureCDI : SubtargetFeature<"avx512cd", "HasCDI", "true",
|
2013-07-28 16:28:38 +08:00
|
|
|
"Enable AVX-512 Conflict Detection Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
2017-05-25 21:45:23 +08:00
|
|
|
def FeatureVPOPCNTDQ : SubtargetFeature<"avx512vpopcntdq", "HasVPOPCNTDQ",
|
|
|
|
|
"true", "Enable AVX-512 Population Count Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
2013-08-21 11:57:57 +08:00
|
|
|
def FeaturePFI : SubtargetFeature<"avx512pf", "HasPFI", "true",
|
2013-07-28 16:28:38 +08:00
|
|
|
"Enable AVX-512 PreFetch Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
2017-12-22 10:30:30 +08:00
|
|
|
def FeaturePREFETCHWT1 : SubtargetFeature<"prefetchwt1", "HasPREFETCHWT1",
|
2016-01-24 18:41:28 +08:00
|
|
|
"true",
|
|
|
|
|
"Prefetch with Intent to Write and T1 Hint">;
|
2014-07-21 22:54:21 +08:00
|
|
|
def FeatureDQI : SubtargetFeature<"avx512dq", "HasDQI", "true",
|
|
|
|
|
"Enable AVX-512 Doubleword and Quadword Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
|
|
|
|
def FeatureBWI : SubtargetFeature<"avx512bw", "HasBWI", "true",
|
|
|
|
|
"Enable AVX-512 Byte and Word Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
|
|
|
|
def FeatureVLX : SubtargetFeature<"avx512vl", "HasVLX", "true",
|
|
|
|
|
"Enable AVX-512 Vector Length eXtensions",
|
|
|
|
|
[FeatureAVX512]>;
|
2016-01-17 21:42:12 +08:00
|
|
|
def FeatureVBMI : SubtargetFeature<"avx512vbmi", "HasVBMI", "true",
|
2016-11-09 12:50:48 +08:00
|
|
|
"Enable AVX-512 Vector Byte Manipulation Instructions",
|
|
|
|
|
[FeatureBWI]>;
|
2017-11-21 17:48:44 +08:00
|
|
|
def FeatureVBMI2 : SubtargetFeature<"avx512vbmi2", "HasVBMI2", "true",
|
|
|
|
|
"Enable AVX-512 further Vector Byte Manipulation Instructions",
|
|
|
|
|
[FeatureBWI]>;
|
2016-02-08 09:23:15 +08:00
|
|
|
def FeatureIFMA : SubtargetFeature<"avx512ifma", "HasIFMA", "true",
|
2016-01-24 18:41:28 +08:00
|
|
|
"Enable AVX-512 Integer Fused Multiple-Add",
|
|
|
|
|
[FeatureAVX512]>;
|
2015-12-15 21:35:29 +08:00
|
|
|
def FeaturePKU : SubtargetFeature<"pku", "HasPKU", "true",
|
|
|
|
|
"Enable protection keys">;
|
2017-11-21 18:04:28 +08:00
|
|
|
def FeatureVNNI : SubtargetFeature<"avx512vnni", "HasVNNI", "true",
|
|
|
|
|
"Enable AVX-512 Vector Neural Network Instructions",
|
|
|
|
|
[FeatureAVX512]>;
|
2017-11-21 18:32:42 +08:00
|
|
|
def FeatureBITALG : SubtargetFeature<"avx512bitalg", "HasBITALG", "true",
|
|
|
|
|
"Enable AVX-512 Bit Algorithms",
|
|
|
|
|
[FeatureBWI]>;
|
2012-05-31 22:34:17 +08:00
|
|
|
def FeaturePCLMUL : SubtargetFeature<"pclmul", "HasPCLMUL", "true",
|
|
|
|
|
"Enable packed carry-less multiplication instructions",
|
2012-05-01 13:28:32 +08:00
|
|
|
[FeatureSSE2]>;
|
2017-11-26 17:36:41 +08:00
|
|
|
def FeatureGFNI : SubtargetFeature<"gfni", "HasGFNI", "true",
|
|
|
|
|
"Enable Galois Field Arithmetic Instructions",
|
|
|
|
|
[FeatureSSE2]>;
|
2017-11-21 17:30:33 +08:00
|
|
|
def FeatureVPCLMULQDQ : SubtargetFeature<"vpclmulqdq", "HasVPCLMULQDQ", "true",
|
|
|
|
|
"Enable vpclmulqdq instructions",
|
|
|
|
|
[FeatureAVX, FeaturePCLMUL]>;
|
2009-06-27 06:46:54 +08:00
|
|
|
def FeatureFMA4 : SubtargetFeature<"fma4", "HasFMA4", "true",
|
2011-12-30 15:16:00 +08:00
|
|
|
"Enable four-operand fused multiple-add",
|
2012-05-01 14:54:48 +08:00
|
|
|
[FeatureAVX, FeatureSSE4A]>;
|
2011-12-30 15:16:00 +08:00
|
|
|
def FeatureXOP : SubtargetFeature<"xop", "HasXOP", "true",
|
2012-05-01 13:41:41 +08:00
|
|
|
"Enable XOP instructions",
|
2012-08-16 12:04:02 +08:00
|
|
|
[FeatureFMA4]>;
|
2015-02-04 01:13:04 +08:00
|
|
|
def FeatureSSEUnalignedMem : SubtargetFeature<"sse-unaligned-mem",
|
|
|
|
|
"HasSSEUnalignedMem", "true",
|
|
|
|
|
"Allow unaligned memory operands with SSE instructions">;
|
2010-04-03 05:54:27 +08:00
|
|
|
def FeatureAES : SubtargetFeature<"aes", "HasAES", "true",
|
2012-05-01 13:28:32 +08:00
|
|
|
"Enable AES instructions",
|
|
|
|
|
[FeatureSSE2]>;
|
2017-11-21 17:11:41 +08:00
|
|
|
def FeatureVAES : SubtargetFeature<"vaes", "HasVAES", "true",
|
|
|
|
|
"Promote selected AES instructions to AVX512/AVX registers",
|
|
|
|
|
[FeatureAVX, FeatureAES]>;
|
2013-09-25 02:21:52 +08:00
|
|
|
def FeatureTBM : SubtargetFeature<"tbm", "HasTBM", "true",
|
|
|
|
|
"Enable TBM instructions">;
|
2017-05-03 23:51:39 +08:00
|
|
|
def FeatureLWP : SubtargetFeature<"lwp", "HasLWP", "true",
|
|
|
|
|
"Enable LWP instructions">;
|
2011-10-04 01:28:23 +08:00
|
|
|
def FeatureMOVBE : SubtargetFeature<"movbe", "HasMOVBE", "true",
|
|
|
|
|
"Support MOVBE instruction">;
|
2013-08-24 04:21:34 +08:00
|
|
|
def FeatureRDRAND : SubtargetFeature<"rdrnd", "HasRDRAND", "true",
|
2011-10-04 01:28:23 +08:00
|
|
|
"Support RDRAND instruction">;
|
2011-10-31 03:57:21 +08:00
|
|
|
def FeatureFSGSBase : SubtargetFeature<"fsgsbase", "HasFSGSBase", "true",
|
|
|
|
|
"Support FS/GS Base instructions">;
|
2011-10-11 14:44:02 +08:00
|
|
|
def FeatureLZCNT : SubtargetFeature<"lzcnt", "HasLZCNT", "true",
|
|
|
|
|
"Support LZCNT instruction">;
|
2011-10-14 11:21:46 +08:00
|
|
|
def FeatureBMI : SubtargetFeature<"bmi", "HasBMI", "true",
|
|
|
|
|
"Support BMI instructions">;
|
2011-10-16 15:55:05 +08:00
|
|
|
def FeatureBMI2 : SubtargetFeature<"bmi2", "HasBMI2", "true",
|
|
|
|
|
"Support BMI2 instructions">;
|
2012-11-08 15:28:54 +08:00
|
|
|
def FeatureRTM : SubtargetFeature<"rtm", "HasRTM", "true",
|
|
|
|
|
"Support RTM instructions">;
|
2013-02-15 03:08:21 +08:00
|
|
|
def FeatureADX : SubtargetFeature<"adx", "HasADX", "true",
|
|
|
|
|
"Support ADX instructions">;
|
2013-09-12 23:51:31 +08:00
|
|
|
def FeatureSHA : SubtargetFeature<"sha", "HasSHA", "true",
|
|
|
|
|
"Enable SHA instructions",
|
|
|
|
|
[FeatureSSE2]>;
|
2017-11-26 21:02:45 +08:00
|
|
|
def FeatureSHSTK : SubtargetFeature<"shstk", "HasSHSTK", "true",
|
|
|
|
|
"Support CET Shadow-Stack instructions">;
|
2013-03-27 01:47:11 +08:00
|
|
|
def FeaturePRFCHW : SubtargetFeature<"prfchw", "HasPRFCHW", "true",
|
|
|
|
|
"Support PRFCHW instructions">;
|
2013-03-29 07:41:26 +08:00
|
|
|
def FeatureRDSEED : SubtargetFeature<"rdseed", "HasRDSEED", "true",
|
|
|
|
|
"Support RDSEED instruction">;
|
2015-12-05 07:00:33 +08:00
|
|
|
def FeatureLAHFSAHF : SubtargetFeature<"sahf", "HasLAHFSAHF", "true",
|
|
|
|
|
"Support LAHF and SAHF instructions">;
|
2016-05-18 19:59:12 +08:00
|
|
|
def FeatureMWAITX : SubtargetFeature<"mwaitx", "HasMWAITX", "true",
|
|
|
|
|
"Enable MONITORX/MWAITX timer functionality">;
|
2017-02-09 12:27:34 +08:00
|
|
|
def FeatureCLZERO : SubtargetFeature<"clzero", "HasCLZERO", "true",
|
|
|
|
|
"Enable Cache Line Zero">;
|
2018-04-13 15:35:08 +08:00
|
|
|
def FeatureCLDEMOTE : SubtargetFeature<"cldemote", "HasCLDEMOTE", "true",
|
|
|
|
|
"Enable Cache Demote">;
|
2018-05-10 15:26:05 +08:00
|
|
|
def FeaturePTWRITE : SubtargetFeature<"ptwrite", "HasPTWRITE", "true",
|
|
|
|
|
"Support ptwrite instruction">;
|
2015-06-03 18:30:57 +08:00
|
|
|
def FeatureMPX : SubtargetFeature<"mpx", "HasMPX", "true",
|
|
|
|
|
"Support MPX instructions">;
|
2015-10-12 23:24:01 +08:00
|
|
|
def FeatureLEAForSP : SubtargetFeature<"lea-sp", "UseLeaForSP", "true",
|
2012-02-08 06:50:41 +08:00
|
|
|
"Use LEA for adjusting the stack pointer">;
|
2014-11-21 19:19:34 +08:00
|
|
|
def FeatureSlowDivide32 : SubtargetFeature<"idivl-to-divb",
|
|
|
|
|
"HasSlowDivide32", "true",
|
|
|
|
|
"Use 8-bit divide for positive values less than 256">;
|
2017-01-13 03:34:15 +08:00
|
|
|
def FeatureSlowDivide64 : SubtargetFeature<"idivq-to-divl",
|
2014-11-21 19:19:34 +08:00
|
|
|
"HasSlowDivide64", "true",
|
2017-01-13 03:34:15 +08:00
|
|
|
"Use 32-bit divide for positive values less than 2^32">;
|
2013-01-09 02:27:24 +08:00
|
|
|
def FeaturePadShortFunctions : SubtargetFeature<"pad-short-functions",
|
|
|
|
|
"PadShortFunctions", "true",
|
|
|
|
|
"Pad short functions">;
|
2018-05-25 14:32:05 +08:00
|
|
|
def FeatureINVPCID : SubtargetFeature<"invpcid", "HasINVPCID", "true",
|
|
|
|
|
"Invalidate Process-Context Identifier">;
|
2016-01-24 18:41:28 +08:00
|
|
|
def FeatureSGX : SubtargetFeature<"sgx", "HasSGX", "true",
|
|
|
|
|
"Enable Software Guard Extensions">;
|
|
|
|
|
def FeatureCLFLUSHOPT : SubtargetFeature<"clflushopt", "HasCLFLUSHOPT", "true",
|
|
|
|
|
"Flush A Cache Line Optimized">;
|
|
|
|
|
def FeatureCLWB : SubtargetFeature<"clwb", "HasCLWB", "true",
|
|
|
|
|
"Cache Line Write Back">;
|
2018-04-12 04:01:57 +08:00
|
|
|
def FeatureWBNOINVD : SubtargetFeature<"wbnoinvd", "HasWBNOINVD", "true",
|
|
|
|
|
"Write Back No Invalidate">;
|
2018-01-19 07:52:31 +08:00
|
|
|
def FeatureRDPID : SubtargetFeature<"rdpid", "HasRDPID", "true",
|
|
|
|
|
"Support RDPID instructions">;
|
2018-04-21 02:42:47 +08:00
|
|
|
def FeatureWAITPKG : SubtargetFeature<"waitpkg", "HasWAITPKG", "true",
|
|
|
|
|
"Wait and pause enhancements">;
|
2017-08-29 13:14:27 +08:00
|
|
|
// On some processors, instructions that implicitly take two memory operands are
|
|
|
|
|
// slow. In practice, this means that CALL, PUSH, and POP with memory operands
|
|
|
|
|
// should be avoided in favor of a MOV + register CALL/PUSH/POP.
|
|
|
|
|
def FeatureSlowTwoMemOps : SubtargetFeature<"slow-two-mem-ops",
|
|
|
|
|
"SlowTwoMemOps", "true",
|
|
|
|
|
"Two memory operand instructions are slow">;
|
2013-04-26 04:29:37 +08:00
|
|
|
def FeatureLEAUsesAG : SubtargetFeature<"lea-uses-ag", "LEAUsesAG", "true",
|
|
|
|
|
"LEA instruction needs inputs at AG stage">;
|
2014-05-20 16:55:50 +08:00
|
|
|
def FeatureSlowLEA : SubtargetFeature<"slow-lea", "SlowLEA", "true",
|
|
|
|
|
"LEA instruction with certain arguments is slow">;
|
2017-05-18 16:11:50 +08:00
|
|
|
def FeatureSlow3OpsLEA : SubtargetFeature<"slow-3ops-lea", "Slow3OpsLEA", "true",
|
|
|
|
|
"LEA instruction with 3 ops or certain registers is slow">;
|
2014-06-09 19:40:41 +08:00
|
|
|
def FeatureSlowIncDec : SubtargetFeature<"slow-incdec", "SlowIncDec", "true",
|
|
|
|
|
"INC and DEC instructions are slower than ADD and SUB">;
|
2015-05-12 09:26:05 +08:00
|
|
|
def FeatureSoftFloat
|
|
|
|
|
: SubtargetFeature<"soft-float", "UseSoftFloat", "true",
|
|
|
|
|
"Use software floating point features.">;
|
2018-01-22 18:07:01 +08:00
|
|
|
def FeaturePOPCNTFalseDeps : SubtargetFeature<"false-deps-popcnt",
|
|
|
|
|
"HasPOPCNTFalseDeps", "true",
|
|
|
|
|
"POPCNT has a false dependency on dest register">;
|
|
|
|
|
def FeatureLZCNTFalseDeps : SubtargetFeature<"false-deps-lzcnt-tzcnt",
|
|
|
|
|
"HasLZCNTFalseDeps", "true",
|
|
|
|
|
"LZCNT/TZCNT have a false dependency on dest register">;
|
2018-05-08 14:47:36 +08:00
|
|
|
def FeaturePCONFIG : SubtargetFeature<"pconfig", "HasPCONFIG", "true",
|
|
|
|
|
"platform configuration instruction">;
|
2017-12-19 21:16:43 +08:00
|
|
|
// On recent X86 (port bound) processors, its preferable to combine to a single shuffle
|
|
|
|
|
// using a variable mask over multiple fixed shuffles.
|
|
|
|
|
def FeatureFastVariableShuffle
|
|
|
|
|
: SubtargetFeature<"fast-variable-shuffle",
|
|
|
|
|
"HasFastVariableShuffle",
|
|
|
|
|
"true", "Shuffles with variable masks are fast">;
|
2017-03-03 17:03:24 +08:00
|
|
|
// On some X86 processors, there is no performance hazard to writing only the
|
|
|
|
|
// lower parts of a YMM or ZMM register without clearing the upper part.
|
|
|
|
|
def FeatureFastPartialYMMorZMMWrite
|
|
|
|
|
: SubtargetFeature<"fast-partial-ymm-or-zmm-write",
|
|
|
|
|
"HasFastPartialYMMorZMMWrite",
|
|
|
|
|
"true", "Partial writes to YMM/ZMM registers are fast">;
|
2016-08-04 20:47:28 +08:00
|
|
|
// FeatureFastScalarFSQRT should be enabled if scalar FSQRT has shorter latency
|
|
|
|
|
// than the corresponding NR code. FeatureFastVectorFSQRT should be enabled if
|
|
|
|
|
// vector FSQRT has higher throughput than the corresponding NR code.
|
|
|
|
|
// The idea is that throughput bound code is likely to be vectorized, so for
|
|
|
|
|
// vectorized code we should care about the throughput of SQRT operations.
|
|
|
|
|
// But if the code is scalar that probably means that the code has some kind of
|
|
|
|
|
// dependency and we should care more about reducing the latency.
|
|
|
|
|
def FeatureFastScalarFSQRT
|
|
|
|
|
: SubtargetFeature<"fast-scalar-fsqrt", "HasFastScalarFSQRT",
|
|
|
|
|
"true", "Scalar SQRT is fast (disable Newton-Raphson)">;
|
|
|
|
|
def FeatureFastVectorFSQRT
|
|
|
|
|
: SubtargetFeature<"fast-vector-fsqrt", "HasFastVectorFSQRT",
|
|
|
|
|
"true", "Vector SQRT is fast (disable Newton-Raphson)">;
|
2016-10-15 00:41:38 +08:00
|
|
|
// If lzcnt has equivalent latency/throughput to most simple integer ops, it can
|
|
|
|
|
// be used to replace test/set sequences.
|
|
|
|
|
def FeatureFastLZCNT
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"fast-lzcnt", "HasFastLZCNT", "true",
|
|
|
|
|
"LZCNT instructions are as fast as most simple integer ops">;
|
2018-01-30 05:24:31 +08:00
|
|
|
// If the target can efficiently decode NOPs upto 11-bytes in length.
|
|
|
|
|
def FeatureFast11ByteNOP
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"fast-11bytenop", "HasFast11ByteNOP", "true",
|
|
|
|
|
"Target can quickly decode up to 11 byte NOPs">;
|
|
|
|
|
// If the target can efficiently decode NOPs upto 15-bytes in length.
|
|
|
|
|
def FeatureFast15ByteNOP
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"fast-15bytenop", "HasFast15ByteNOP", "true",
|
|
|
|
|
"Target can quickly decode up to 15 byte NOPs">;
|
2017-02-21 14:39:13 +08:00
|
|
|
// Sandy Bridge and newer processors can use SHLD with the same source on both
|
|
|
|
|
// inputs to implement rotate to avoid the partial flag update of the normal
|
|
|
|
|
// rotate instructions.
|
|
|
|
|
def FeatureFastSHLDRotate
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"fast-shld-rotate", "HasFastSHLDRotate", "true",
|
|
|
|
|
"SHLD can be used as a faster rotate">;
|
|
|
|
|
|
2017-04-21 17:20:50 +08:00
|
|
|
// Ivy Bridge and newer processors have enhanced REP MOVSB and STOSB (aka
|
|
|
|
|
// "string operations"). See "REP String Enhancement" in the Intel Software
|
2017-04-21 17:21:05 +08:00
|
|
|
// Development Manual. This feature essentially means that REP MOVSB will copy
|
2017-04-21 17:20:50 +08:00
|
|
|
// using the largest available size instead of copying bytes one by one, making
|
|
|
|
|
// it at least as fast as REPMOVS{W,D,Q}.
|
|
|
|
|
def FeatureERMSB
|
2017-04-21 17:20:39 +08:00
|
|
|
: SubtargetFeature<
|
2017-04-21 17:20:50 +08:00
|
|
|
"ermsb", "HasERMSB", "true",
|
2017-04-21 17:20:39 +08:00
|
|
|
"REP MOVS/STOS are fast">;
|
|
|
|
|
|
2017-08-30 12:34:48 +08:00
|
|
|
// Sandy Bridge and newer processors have many instructions that can be
|
|
|
|
|
// fused with conditional branches and pass through the CPU as a single
|
|
|
|
|
// operation.
|
|
|
|
|
def FeatureMacroFusion
|
|
|
|
|
: SubtargetFeature<"macrofusion", "HasMacroFusion", "true",
|
|
|
|
|
"Various instructions can be fused with conditional branches">;
|
|
|
|
|
|
2017-11-26 02:09:37 +08:00
|
|
|
// Gather is available since Haswell (AVX2 set). So technically, we can
|
|
|
|
|
// generate Gathers on all AVX2 processors. But the overhead on HSW is high.
|
|
|
|
|
// Skylake Client processor has faster Gathers than HSW and performance is
|
|
|
|
|
// similar to Skylake Server (AVX-512).
|
|
|
|
|
def FeatureHasFastGather
|
|
|
|
|
: SubtargetFeature<"fast-gather", "HasFastGather", "true",
|
|
|
|
|
"Indicates if gather is reasonably fast.">;
|
|
|
|
|
|
2018-01-20 08:26:08 +08:00
|
|
|
def FeaturePrefer256Bit
|
|
|
|
|
: SubtargetFeature<"prefer-256-bit", "Prefer256Bit", "true",
|
|
|
|
|
"Prefer 256-bit AVX instructions">;
|
|
|
|
|
|
2018-08-23 14:06:38 +08:00
|
|
|
// Lower indirect calls using a special construct called a `retpoline` to
|
|
|
|
|
// mitigate potential Spectre v2 attacks against them.
|
|
|
|
|
def FeatureRetpolineIndirectCalls
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"retpoline-indirect-calls", "UseRetpolineIndirectCalls", "true",
|
|
|
|
|
"Remove speculation of indirect calls from the generated code.">;
|
|
|
|
|
|
|
|
|
|
// Lower indirect branches and switches either using conditional branch trees
|
|
|
|
|
// or using a special construct called a `retpoline` to mitigate potential
|
|
|
|
|
// Spectre v2 attacks against them.
|
|
|
|
|
def FeatureRetpolineIndirectBranches
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"retpoline-indirect-branches", "UseRetpolineIndirectBranches", "true",
|
|
|
|
|
"Remove speculation of indirect branches from the generated code.">;
|
|
|
|
|
|
|
|
|
|
// Deprecated umbrella feature for enabling both `retpoline-indirect-calls` and
|
|
|
|
|
// `retpoline-indirect-branches` above.
|
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
2018-01-23 06:05:25 +08:00
|
|
|
def FeatureRetpoline
|
2018-08-23 14:06:38 +08:00
|
|
|
: SubtargetFeature<"retpoline", "DeprecatedUseRetpoline", "true",
|
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
2018-01-23 06:05:25 +08:00
|
|
|
"Remove speculation of indirect branches from the "
|
|
|
|
|
"generated code, either by avoiding them entirely or "
|
2018-08-23 14:06:38 +08:00
|
|
|
"lowering them with a speculation blocking construct.",
|
|
|
|
|
[FeatureRetpolineIndirectCalls,
|
|
|
|
|
FeatureRetpolineIndirectBranches]>;
|
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
2018-01-23 06:05:25 +08:00
|
|
|
|
|
|
|
|
// Rely on external thunks for the emitted retpoline calls. This allows users
|
|
|
|
|
// to provide their own custom thunk definitions in highly specialized
|
|
|
|
|
// environments such as a kernel that does boot-time hot patching.
|
|
|
|
|
def FeatureRetpolineExternalThunk
|
|
|
|
|
: SubtargetFeature<
|
|
|
|
|
"retpoline-external-thunk", "UseRetpolineExternalThunk", "true",
|
2018-08-23 14:06:38 +08:00
|
|
|
"When lowering an indirect call or branch using a `retpoline`, rely "
|
|
|
|
|
"on the specified user provided thunk rather than emitting one "
|
|
|
|
|
"ourselves. Only has effect when combined with some other retpoline "
|
|
|
|
|
"feature.", [FeatureRetpolineIndirectCalls]>;
|
Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to Spectre..
Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.
The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.
However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.
On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.
This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886
We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
__llvm_external_retpoline_r11
```
or on 32-bit:
```
__llvm_external_retpoline_eax
__llvm_external_retpoline_ecx
__llvm_external_retpoline_edx
__llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.
There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.
The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.
For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding allows the
retpoline-mitigated PLT to be substantially smaller.
When manually apply similar transformations to `-mretpoline` to the
Linux kernel we observed very small performance hits to applications
running typical workloads, and relatively minor hits (approximately 2%)
even for extremely syscall-heavy applications. This is largely due to
the small number of indirect branches that occur in performance
sensitive paths of the kernel.
When using these patches on statically linked applications, especially
C++ applications, you should expect to see a much more dramatic
performance hit. For microbenchmarks that are switch, indirect-, or
virtual-call heavy we have seen overheads ranging from 10% to 50%.
However, real-world workloads exhibit substantially lower performance
impact. Notably, techniques such as PGO and ThinLTO dramatically reduce
the impact of hot indirect calls (by speculatively promoting them to
direct calls) and allow optimized search trees to be used to lower
switches. If you need to deploy these techniques in C++ applications, we
*strongly* recommend that you ensure all hot call targets are statically
linked (avoiding PLT indirection) and use both PGO and ThinLTO. Well
tuned servers using all of these techniques saw 5% - 10% overhead from
the use of retpoline.
We will add detailed documentation covering these components in
subsequent patches, but wanted to make the core functionality available
as soon as possible. Happy for more code review, but we'd really like to
get these patches landed and backported ASAP for obvious reasons. We're
planning to backport this to both 6.0 and 5.0 release streams and get
a 5.0 release with just this cherry picked ASAP for distros and vendors.
This patch is the work of a number of people over the past month: Eric, Reid,
Rui, and myself. I'm mailing it out as a single commit due to the time
sensitive nature of landing this and the need to backport it. Huge thanks to
everyone who helped out here, and everyone at Intel who helped out in
discussions about how to craft this. Also, credit goes to Paul Turner (at
Google, but not an LLVM contributor) for much of the underlying retpoline
design.
Reviewers: echristo, rnk, ruiu, craig.topper, DavidKreitzer
Subscribers: sanjoy, emaste, mcrosier, mgorny, mehdi_amini, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D41723
llvm-svn: 323155
2018-01-23 06:05:25 +08:00
|
|
|
|
2018-05-01 18:01:16 +08:00
|
|
|
// Direct Move instructions.
|
|
|
|
|
def FeatureMOVDIRI : SubtargetFeature<"movdiri", "HasMOVDIRI", "true",
|
|
|
|
|
"Support movdiri instruction">;
|
|
|
|
|
def FeatureMOVDIR64B : SubtargetFeature<"movdir64b", "HasMOVDIR64B", "true",
|
|
|
|
|
"Support movdir64b instruction">;
|
|
|
|
|
|
2018-09-30 11:01:46 +08:00
|
|
|
def FeatureFastBEXTR : SubtargetFeature<"fast-bextr", "HasFastBEXTR", "true",
|
|
|
|
|
"Indicates that the BEXTR instruction is implemented as a single uop "
|
|
|
|
|
"with good throughput.">;
|
|
|
|
|
|
2006-10-06 17:17:41 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
2017-12-11 01:42:36 +08:00
|
|
|
// Register File Description
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "X86RegisterInfo.td"
|
|
|
|
|
include "X86RegisterBanks.td"
|
|
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Instruction Descriptions
|
2006-10-06 17:17:41 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2012-02-02 07:20:51 +08:00
|
|
|
include "X86Schedule.td"
|
2017-12-11 01:42:36 +08:00
|
|
|
include "X86InstrInfo.td"
|
2018-07-20 00:42:15 +08:00
|
|
|
include "X86SchedPredicates.td"
|
2017-12-11 01:42:36 +08:00
|
|
|
|
|
|
|
|
def X86InstrInfo : InstrInfo;
|
|
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// X86 processors supported.
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "X86ScheduleAtom.td"
|
|
|
|
|
include "X86SchedSandyBridge.td"
|
|
|
|
|
include "X86SchedHaswell.td"
|
|
|
|
|
include "X86SchedBroadwell.td"
|
|
|
|
|
include "X86ScheduleSLM.td"
|
|
|
|
|
include "X86ScheduleZnver1.td"
|
|
|
|
|
include "X86ScheduleBtVer2.td"
|
|
|
|
|
include "X86SchedSkylakeClient.td"
|
|
|
|
|
include "X86SchedSkylakeServer.td"
|
2012-02-02 07:20:51 +08:00
|
|
|
|
|
|
|
|
def ProcIntelAtom : SubtargetFeature<"atom", "X86ProcFamily", "IntelAtom",
|
|
|
|
|
"Intel Atom processors">;
|
2013-09-14 03:23:28 +08:00
|
|
|
def ProcIntelSLM : SubtargetFeature<"slm", "X86ProcFamily", "IntelSLM",
|
|
|
|
|
"Intel Silvermont processors">;
|
2017-06-29 18:00:33 +08:00
|
|
|
def ProcIntelGLM : SubtargetFeature<"glm", "X86ProcFamily", "IntelGLM",
|
|
|
|
|
"Intel Goldmont processors">;
|
2018-04-16 15:47:35 +08:00
|
|
|
def ProcIntelGLP : SubtargetFeature<"glp", "X86ProcFamily", "IntelGLP",
|
|
|
|
|
"Intel Goldmont Plus processors">;
|
|
|
|
|
def ProcIntelTRM : SubtargetFeature<"tremont", "X86ProcFamily", "IntelTRM",
|
|
|
|
|
"Intel Tremont processors">;
|
2017-09-13 17:00:27 +08:00
|
|
|
def ProcIntelHSW : SubtargetFeature<"haswell", "X86ProcFamily",
|
|
|
|
|
"IntelHaswell", "Intel Haswell processors">;
|
|
|
|
|
def ProcIntelBDW : SubtargetFeature<"broadwell", "X86ProcFamily",
|
|
|
|
|
"IntelBroadwell", "Intel Broadwell processors">;
|
|
|
|
|
def ProcIntelSKL : SubtargetFeature<"skylake", "X86ProcFamily",
|
|
|
|
|
"IntelSkylake", "Intel Skylake processors">;
|
|
|
|
|
def ProcIntelKNL : SubtargetFeature<"knl", "X86ProcFamily",
|
|
|
|
|
"IntelKNL", "Intel Knights Landing processors">;
|
|
|
|
|
def ProcIntelSKX : SubtargetFeature<"skx", "X86ProcFamily",
|
|
|
|
|
"IntelSKX", "Intel Skylake Server processors">;
|
|
|
|
|
def ProcIntelCNL : SubtargetFeature<"cannonlake", "X86ProcFamily",
|
|
|
|
|
"IntelCannonlake", "Intel Cannonlake processors">;
|
2018-04-11 02:59:13 +08:00
|
|
|
def ProcIntelICL : SubtargetFeature<"icelake-client", "X86ProcFamily",
|
|
|
|
|
"IntelIcelakeClient", "Intel Icelake processors">;
|
|
|
|
|
def ProcIntelICX : SubtargetFeature<"icelake-server", "X86ProcFamily",
|
|
|
|
|
"IntelIcelakeServer", "Intel Icelake Server processors">;
|
2012-02-02 07:20:51 +08:00
|
|
|
|
2006-10-06 17:17:41 +08:00
|
|
|
class Proc<string Name, list<SubtargetFeature> Features>
|
2012-07-07 12:00:00 +08:00
|
|
|
: ProcessorModel<Name, GenericModel, Features>;
|
2012-02-02 07:20:51 +08:00
|
|
|
|
2016-03-23 19:13:54 +08:00
|
|
|
def : Proc<"generic", [FeatureX87, FeatureSlowUAMem16]>;
|
|
|
|
|
def : Proc<"i386", [FeatureX87, FeatureSlowUAMem16]>;
|
|
|
|
|
def : Proc<"i486", [FeatureX87, FeatureSlowUAMem16]>;
|
|
|
|
|
def : Proc<"i586", [FeatureX87, FeatureSlowUAMem16]>;
|
|
|
|
|
def : Proc<"pentium", [FeatureX87, FeatureSlowUAMem16]>;
|
|
|
|
|
def : Proc<"pentium-mmx", [FeatureX87, FeatureSlowUAMem16, FeatureMMX]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
|
2018-01-11 06:07:16 +08:00
|
|
|
def : Proc<"i686", [FeatureX87, FeatureSlowUAMem16, FeatureCMOV]>;
|
|
|
|
|
def : Proc<"pentiumpro", [FeatureX87, FeatureSlowUAMem16, FeatureCMOV,
|
|
|
|
|
FeatureNOPL]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
|
2016-03-23 19:13:54 +08:00
|
|
|
def : Proc<"pentium2", [FeatureX87, FeatureSlowUAMem16, FeatureMMX,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureCMOV, FeatureFXSR, FeatureNOPL]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
|
|
|
|
|
foreach P = ["pentium3", "pentium3m"] in {
|
|
|
|
|
def : Proc<P, [FeatureX87, FeatureSlowUAMem16, FeatureMMX, FeatureSSE1,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureFXSR, FeatureNOPL, FeatureCMOV]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
2016-04-28 06:52:35 +08:00
|
|
|
|
|
|
|
|
// Enable the PostRAScheduler for SSE2 and SSE3 class cpus.
|
|
|
|
|
// The intent is to enable it for pentium4 which is the current default
|
|
|
|
|
// processor in a vanilla 32-bit clang compilation when no specific
|
|
|
|
|
// architecture is specified. This generally gives a nice performance
|
|
|
|
|
// increase on silvermont, with largely neutral behavior on other
|
|
|
|
|
// contemporary large core processors.
|
|
|
|
|
// pentium-m, pentium4m, prescott and nocona are included as a preventative
|
|
|
|
|
// measure to avoid performance surprises, in case clang's default cpu
|
|
|
|
|
// changes slightly.
|
|
|
|
|
|
|
|
|
|
def : ProcessorModel<"pentium-m", GenericPostRAModel,
|
|
|
|
|
[FeatureX87, FeatureSlowUAMem16, FeatureMMX,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureSSE2, FeatureFXSR, FeatureNOPL, FeatureCMOV]>;
|
2016-04-28 06:52:35 +08:00
|
|
|
|
2017-11-02 06:15:49 +08:00
|
|
|
foreach P = ["pentium4", "pentium4m"] in {
|
|
|
|
|
def : ProcessorModel<P, GenericPostRAModel,
|
|
|
|
|
[FeatureX87, FeatureSlowUAMem16, FeatureMMX,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureSSE2, FeatureFXSR, FeatureNOPL, FeatureCMOV]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
2014-05-08 01:37:03 +08:00
|
|
|
|
2016-04-01 18:16:15 +08:00
|
|
|
// Intel Quark.
|
|
|
|
|
def : Proc<"lakemont", []>;
|
|
|
|
|
|
2013-03-27 06:19:12 +08:00
|
|
|
// Intel Core Duo.
|
2015-10-16 14:03:09 +08:00
|
|
|
def : ProcessorModel<"yonah", SandyBridgeModel,
|
2016-03-23 19:13:54 +08:00
|
|
|
[FeatureX87, FeatureSlowUAMem16, FeatureMMX, FeatureSSE3,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureFXSR, FeatureNOPL, FeatureCMOV]>;
|
2013-03-27 06:19:12 +08:00
|
|
|
|
|
|
|
|
// NetBurst.
|
2016-04-28 06:52:35 +08:00
|
|
|
def : ProcessorModel<"prescott", GenericPostRAModel,
|
|
|
|
|
[FeatureX87, FeatureSlowUAMem16, FeatureMMX, FeatureSSE3,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureFXSR, FeatureNOPL, FeatureCMOV]>;
|
2016-04-28 06:52:35 +08:00
|
|
|
def : ProcessorModel<"nocona", GenericPostRAModel, [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSlowUAMem16,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE3,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
2017-10-16 00:57:33 +08:00
|
|
|
FeatureCMPXCHG16B
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2013-03-27 06:19:12 +08:00
|
|
|
|
|
|
|
|
// Intel Core 2 Solo/Duo.
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : ProcessorModel<"core2", SandyBridgeModel, [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSlowUAMem16,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSSE3,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
|
|
|
|
def : ProcessorModel<"penryn", SandyBridgeModel, [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSlowUAMem16,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE41,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2013-03-27 06:19:12 +08:00
|
|
|
|
2014-12-09 18:58:36 +08:00
|
|
|
// Atom CPUs.
|
|
|
|
|
class BonnellProc<string Name> : ProcessorModel<Name, AtomModel, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
ProcIntelAtom,
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSlowUAMem16,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSSE3,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureMOVBE,
|
2015-10-12 23:24:01 +08:00
|
|
|
FeatureLEAForSP,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSlowDivide32,
|
|
|
|
|
FeatureSlowDivide64,
|
2017-08-29 13:14:27 +08:00
|
|
|
FeatureSlowTwoMemOps,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureLEAUsesAG,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeaturePadShortFunctions,
|
|
|
|
|
FeatureLAHFSAHF
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : BonnellProc<"bonnell">;
|
|
|
|
|
def : BonnellProc<"atom">; // Pin the generic name to the baseline.
|
|
|
|
|
|
|
|
|
|
class SilvermontProc<string Name> : ProcessorModel<Name, SLMModel, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
ProcIntelSLM,
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE42,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureMOVBE,
|
|
|
|
|
FeaturePOPCNT,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureSlowDivide64,
|
2017-08-29 13:14:27 +08:00
|
|
|
FeatureSlowTwoMemOps,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeatureSlowLEA,
|
|
|
|
|
FeatureSlowIncDec,
|
2016-12-07 03:35:20 +08:00
|
|
|
FeatureSlowPMULLD,
|
2018-01-27 03:34:14 +08:00
|
|
|
FeatureRDRAND,
|
2018-04-20 03:25:24 +08:00
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeaturePOPCNTFalseDeps
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : SilvermontProc<"silvermont">;
|
|
|
|
|
def : SilvermontProc<"slm">; // Legacy alias.
|
2013-03-27 06:19:12 +08:00
|
|
|
|
2018-04-16 15:47:35 +08:00
|
|
|
class ProcessorFeatures<list<SubtargetFeature> Inherited,
|
|
|
|
|
list<SubtargetFeature> NewFeatures> {
|
|
|
|
|
list<SubtargetFeature> Value = !listconcat(Inherited, NewFeatures);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
class ProcModel<string Name, SchedMachineModel Model,
|
|
|
|
|
list<SubtargetFeature> ProcFeatures,
|
|
|
|
|
list<SubtargetFeature> OtherFeatures> :
|
|
|
|
|
ProcessorModel<Name, Model, !listconcat(ProcFeatures, OtherFeatures)>;
|
|
|
|
|
|
|
|
|
|
def GLMFeatures : ProcessorFeatures<[], [
|
2017-06-29 18:00:33 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
2017-06-29 18:00:33 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE42,
|
|
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
2017-06-29 18:00:33 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureMOVBE,
|
|
|
|
|
FeaturePOPCNT,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeaturePRFCHW,
|
2017-08-29 13:14:27 +08:00
|
|
|
FeatureSlowTwoMemOps,
|
2017-06-29 18:00:33 +08:00
|
|
|
FeatureSlowLEA,
|
|
|
|
|
FeatureSlowIncDec,
|
|
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureMPX,
|
|
|
|
|
FeatureSHA,
|
2017-07-04 13:33:19 +08:00
|
|
|
FeatureRDRAND,
|
2017-06-29 18:00:33 +08:00
|
|
|
FeatureRDSEED,
|
|
|
|
|
FeatureXSAVE,
|
|
|
|
|
FeatureXSAVEOPT,
|
|
|
|
|
FeatureXSAVEC,
|
|
|
|
|
FeatureXSAVES,
|
2017-09-25 21:45:31 +08:00
|
|
|
FeatureCLFLUSHOPT,
|
|
|
|
|
FeatureFSGSBase
|
2017-06-29 18:00:33 +08:00
|
|
|
]>;
|
2018-04-16 15:47:35 +08:00
|
|
|
|
|
|
|
|
class GoldmontProc<string Name> : ProcModel<Name, SLMModel,
|
2018-04-20 03:25:24 +08:00
|
|
|
GLMFeatures.Value, [
|
|
|
|
|
ProcIntelGLM,
|
|
|
|
|
FeaturePOPCNTFalseDeps
|
|
|
|
|
]>;
|
2017-06-29 18:00:33 +08:00
|
|
|
def : GoldmontProc<"goldmont">;
|
|
|
|
|
|
2018-05-10 15:26:05 +08:00
|
|
|
def GLPFeatures : ProcessorFeatures<GLMFeatures.Value, [
|
|
|
|
|
FeaturePTWRITE,
|
2018-04-16 15:47:35 +08:00
|
|
|
FeatureRDPID,
|
|
|
|
|
FeatureSGX
|
|
|
|
|
]>;
|
2018-05-10 15:26:05 +08:00
|
|
|
|
|
|
|
|
class GoldmontPlusProc<string Name> : ProcModel<Name, SLMModel,
|
|
|
|
|
GLPFeatures.Value, [
|
|
|
|
|
ProcIntelGLP
|
|
|
|
|
]>;
|
2018-04-16 15:47:35 +08:00
|
|
|
def : GoldmontPlusProc<"goldmont-plus">;
|
|
|
|
|
|
|
|
|
|
class TremontProc<string Name> : ProcModel<Name, SLMModel,
|
2018-05-10 15:26:05 +08:00
|
|
|
GLPFeatures.Value, [
|
2018-04-16 15:47:35 +08:00
|
|
|
ProcIntelTRM,
|
|
|
|
|
FeatureCLDEMOTE,
|
|
|
|
|
FeatureGFNI,
|
2018-05-01 18:01:16 +08:00
|
|
|
FeatureMOVDIRI,
|
|
|
|
|
FeatureMOVDIR64B,
|
2018-04-21 02:42:47 +08:00
|
|
|
FeatureWAITPKG
|
2018-04-16 15:47:35 +08:00
|
|
|
]>;
|
|
|
|
|
def : TremontProc<"tremont">;
|
|
|
|
|
|
2010-04-03 05:54:27 +08:00
|
|
|
// "Arrandale" along with corei3 and corei5
|
2015-03-30 14:31:11 +08:00
|
|
|
class NehalemProc<string Name> : ProcessorModel<Name, SandyBridgeModel, [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE42,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeaturePOPCNT,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2015-03-30 14:31:11 +08:00
|
|
|
def : NehalemProc<"nehalem">;
|
|
|
|
|
def : NehalemProc<"corei7">;
|
2013-03-27 06:19:12 +08:00
|
|
|
|
2010-04-03 05:54:27 +08:00
|
|
|
// Westmere is a similar machine to nehalem with some additional features.
|
|
|
|
|
// Westmere is the corei3/i5/i7 path from nehalem to sandybridge
|
2014-12-09 18:58:36 +08:00
|
|
|
class WestmereProc<string Name> : ProcessorModel<Name, SandyBridgeModel, [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE42,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeaturePOPCNT,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeaturePCLMUL,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : WestmereProc<"westmere">;
|
|
|
|
|
|
2010-12-10 08:26:57 +08:00
|
|
|
// SSE is not listed here since llvm treats AVX as a reimplementation of SSE,
|
|
|
|
|
// rather than a superset.
|
2016-02-14 05:35:37 +08:00
|
|
|
def SNBFeatures : ProcessorFeatures<[], [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureAVX,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeaturePOPCNT,
|
2017-01-13 03:34:15 +08:00
|
|
|
FeatureSlowDivide64,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureXSAVE,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureXSAVEOPT,
|
2016-08-04 20:47:28 +08:00
|
|
|
FeatureLAHFSAHF,
|
2017-05-18 16:11:50 +08:00
|
|
|
FeatureSlow3OpsLEA,
|
2017-02-21 14:39:13 +08:00
|
|
|
FeatureFastScalarFSQRT,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureFastSHLDRotate,
|
2017-08-30 13:00:35 +08:00
|
|
|
FeatureSlowIncDec,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2016-01-24 18:41:28 +08:00
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
class SandyBridgeProc<string Name> : ProcModel<Name, SandyBridgeModel,
|
|
|
|
|
SNBFeatures.Value, [
|
2018-01-22 18:07:01 +08:00
|
|
|
FeatureSlowUAMem32,
|
|
|
|
|
FeaturePOPCNTFalseDeps
|
2016-01-24 18:41:28 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : SandyBridgeProc<"sandybridge">;
|
|
|
|
|
def : SandyBridgeProc<"corei7-avx">; // Legacy alias.
|
2006-10-06 17:17:41 +08:00
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
def IVBFeatures : ProcessorFeatures<SNBFeatures.Value, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureRDRAND,
|
|
|
|
|
FeatureF16C,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeatureFSGSBase
|
|
|
|
|
]>;
|
|
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
class IvyBridgeProc<string Name> : ProcModel<Name, SandyBridgeModel,
|
|
|
|
|
IVBFeatures.Value, [
|
2018-01-22 18:07:01 +08:00
|
|
|
FeatureSlowUAMem32,
|
|
|
|
|
FeaturePOPCNTFalseDeps
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : IvyBridgeProc<"ivybridge">;
|
|
|
|
|
def : IvyBridgeProc<"core-avx-i">; // Legacy alias.
|
|
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
def HSWFeatures : ProcessorFeatures<IVBFeatures.Value, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureAVX2,
|
|
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureBMI2,
|
2017-04-21 17:20:50 +08:00
|
|
|
FeatureERMSB,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureFMA,
|
2018-05-25 14:32:05 +08:00
|
|
|
FeatureINVPCID,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeatureLZCNT,
|
2017-12-19 21:16:43 +08:00
|
|
|
FeatureMOVBE,
|
|
|
|
|
FeatureFastVariableShuffle
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2016-01-24 18:41:28 +08:00
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
class HaswellProc<string Name> : ProcModel<Name, HaswellModel,
|
2017-09-13 17:00:27 +08:00
|
|
|
HSWFeatures.Value, [
|
2018-01-22 18:07:01 +08:00
|
|
|
ProcIntelHSW,
|
|
|
|
|
FeaturePOPCNTFalseDeps,
|
|
|
|
|
FeatureLZCNTFalseDeps
|
2017-10-14 00:04:08 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : HaswellProc<"haswell">;
|
|
|
|
|
def : HaswellProc<"core-avx2">; // Legacy alias.
|
|
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
def BDWFeatures : ProcessorFeatures<HSWFeatures.Value, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureADX,
|
2017-12-22 10:41:12 +08:00
|
|
|
FeatureRDSEED,
|
|
|
|
|
FeaturePRFCHW
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2017-10-25 04:19:47 +08:00
|
|
|
class BroadwellProc<string Name> : ProcModel<Name, BroadwellModel,
|
2017-10-14 00:04:08 +08:00
|
|
|
BDWFeatures.Value, [
|
2018-01-22 18:07:01 +08:00
|
|
|
ProcIntelBDW,
|
|
|
|
|
FeaturePOPCNTFalseDeps,
|
|
|
|
|
FeatureLZCNTFalseDeps
|
2017-10-14 00:04:08 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : BroadwellProc<"broadwell">;
|
2011-10-14 11:21:46 +08:00
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
def SKLFeatures : ProcessorFeatures<BDWFeatures.Value, [
|
2018-09-11 05:12:19 +08:00
|
|
|
FeatureAES,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeatureMPX,
|
2017-03-29 15:40:44 +08:00
|
|
|
FeatureRTM,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeatureXSAVEC,
|
|
|
|
|
FeatureXSAVES,
|
2016-08-04 20:47:28 +08:00
|
|
|
FeatureCLFLUSHOPT,
|
|
|
|
|
FeatureFastVectorFSQRT
|
2016-01-24 18:41:28 +08:00
|
|
|
]>;
|
|
|
|
|
|
2017-09-19 14:19:27 +08:00
|
|
|
class SkylakeClientProc<string Name> : ProcModel<Name, SkylakeClientModel,
|
2017-09-13 17:00:27 +08:00
|
|
|
SKLFeatures.Value, [
|
2017-11-26 02:09:37 +08:00
|
|
|
ProcIntelSKL,
|
2018-01-22 18:07:01 +08:00
|
|
|
FeatureHasFastGather,
|
2018-04-10 21:58:57 +08:00
|
|
|
FeaturePOPCNTFalseDeps,
|
|
|
|
|
FeatureSGX
|
2017-10-14 00:06:06 +08:00
|
|
|
]>;
|
2016-02-22 01:12:03 +08:00
|
|
|
def : SkylakeClientProc<"skylake">;
|
2016-01-24 18:41:28 +08:00
|
|
|
|
2017-10-14 02:10:17 +08:00
|
|
|
def KNLFeatures : ProcessorFeatures<IVBFeatures.Value, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureAVX512,
|
|
|
|
|
FeatureERI,
|
|
|
|
|
FeatureCDI,
|
|
|
|
|
FeaturePFI,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeaturePREFETCHWT1,
|
|
|
|
|
FeatureADX,
|
|
|
|
|
FeatureRDSEED,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMOVBE,
|
|
|
|
|
FeatureLZCNT,
|
|
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureBMI2,
|
2017-12-22 10:41:12 +08:00
|
|
|
FeatureFMA,
|
|
|
|
|
FeaturePRFCHW
|
2017-10-14 02:10:17 +08:00
|
|
|
]>;
|
|
|
|
|
|
|
|
|
|
// FIXME: define KNL model
|
|
|
|
|
class KnightsLandingProc<string Name> : ProcModel<Name, HaswellModel,
|
|
|
|
|
KNLFeatures.Value, [
|
|
|
|
|
ProcIntelKNL,
|
2017-08-29 13:14:27 +08:00
|
|
|
FeatureSlowTwoMemOps,
|
2017-11-26 02:09:37 +08:00
|
|
|
FeatureFastPartialYMMorZMMWrite,
|
|
|
|
|
FeatureHasFastGather
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
def : KnightsLandingProc<"knl">;
|
2013-07-24 19:02:47 +08:00
|
|
|
|
2017-10-14 02:10:17 +08:00
|
|
|
class KnightsMillProc<string Name> : ProcModel<Name, HaswellModel,
|
|
|
|
|
KNLFeatures.Value, [
|
|
|
|
|
ProcIntelKNL,
|
|
|
|
|
FeatureSlowTwoMemOps,
|
2017-10-26 01:10:32 +08:00
|
|
|
FeatureFastPartialYMMorZMMWrite,
|
2017-11-26 02:09:37 +08:00
|
|
|
FeatureHasFastGather,
|
2017-10-26 01:10:32 +08:00
|
|
|
FeatureVPOPCNTDQ
|
2017-10-14 02:10:17 +08:00
|
|
|
]>;
|
|
|
|
|
def : KnightsMillProc<"knm">; // TODO Add AVX5124FMAPS/AVX5124VNNIW features
|
|
|
|
|
|
2016-02-14 05:35:37 +08:00
|
|
|
def SKXFeatures : ProcessorFeatures<SKLFeatures.Value, [
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureAVX512,
|
|
|
|
|
FeatureCDI,
|
|
|
|
|
FeatureDQI,
|
|
|
|
|
FeatureBWI,
|
|
|
|
|
FeatureVLX,
|
2015-12-15 21:35:29 +08:00
|
|
|
FeaturePKU,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeatureCLWB
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-12-09 18:58:36 +08:00
|
|
|
|
2017-10-08 20:52:54 +08:00
|
|
|
class SkylakeServerProc<string Name> : ProcModel<Name, SkylakeServerModel,
|
2017-09-13 17:00:27 +08:00
|
|
|
SKXFeatures.Value, [
|
2017-11-26 02:09:37 +08:00
|
|
|
ProcIntelSKX,
|
2018-01-30 05:56:48 +08:00
|
|
|
FeatureHasFastGather,
|
|
|
|
|
FeaturePOPCNTFalseDeps
|
2017-10-16 00:41:15 +08:00
|
|
|
]>;
|
2016-02-22 01:12:03 +08:00
|
|
|
def : SkylakeServerProc<"skylake-avx512">;
|
2016-01-24 18:41:28 +08:00
|
|
|
def : SkylakeServerProc<"skx">; // Legacy alias.
|
|
|
|
|
|
2018-02-21 08:15:48 +08:00
|
|
|
def CNLFeatures : ProcessorFeatures<SKLFeatures.Value, [
|
|
|
|
|
FeatureAVX512,
|
|
|
|
|
FeatureCDI,
|
|
|
|
|
FeatureDQI,
|
|
|
|
|
FeatureBWI,
|
|
|
|
|
FeatureVLX,
|
|
|
|
|
FeaturePKU,
|
2016-01-18 21:00:31 +08:00
|
|
|
FeatureVBMI,
|
2016-01-24 18:41:28 +08:00
|
|
|
FeatureIFMA,
|
2018-04-10 21:58:57 +08:00
|
|
|
FeatureSHA,
|
|
|
|
|
FeatureSGX
|
2016-01-18 21:00:31 +08:00
|
|
|
]>;
|
2016-01-24 18:41:28 +08:00
|
|
|
|
2017-11-19 09:25:30 +08:00
|
|
|
class CannonlakeProc<string Name> : ProcModel<Name, SkylakeServerModel,
|
2017-09-13 17:00:27 +08:00
|
|
|
CNLFeatures.Value, [
|
2017-11-26 02:09:37 +08:00
|
|
|
ProcIntelCNL,
|
|
|
|
|
FeatureHasFastGather
|
2017-10-14 00:06:06 +08:00
|
|
|
]>;
|
2016-01-18 21:00:31 +08:00
|
|
|
def : CannonlakeProc<"cannonlake">;
|
2014-12-09 18:58:36 +08:00
|
|
|
|
2017-11-19 09:12:00 +08:00
|
|
|
def ICLFeatures : ProcessorFeatures<CNLFeatures.Value, [
|
2017-11-22 05:05:18 +08:00
|
|
|
FeatureBITALG,
|
|
|
|
|
FeatureVAES,
|
|
|
|
|
FeatureVBMI2,
|
|
|
|
|
FeatureVNNI,
|
|
|
|
|
FeatureVPCLMULQDQ,
|
2017-11-26 17:36:41 +08:00
|
|
|
FeatureVPOPCNTDQ,
|
2017-12-28 06:04:04 +08:00
|
|
|
FeatureGFNI,
|
2018-01-19 07:52:31 +08:00
|
|
|
FeatureCLWB,
|
|
|
|
|
FeatureRDPID
|
2017-11-19 09:12:00 +08:00
|
|
|
]>;
|
|
|
|
|
|
2018-04-11 02:59:13 +08:00
|
|
|
class IcelakeClientProc<string Name> : ProcModel<Name, SkylakeServerModel,
|
|
|
|
|
ICLFeatures.Value, [
|
2017-11-26 02:09:37 +08:00
|
|
|
ProcIntelICL,
|
|
|
|
|
FeatureHasFastGather
|
2017-11-19 09:12:00 +08:00
|
|
|
]>;
|
2018-04-11 02:59:13 +08:00
|
|
|
def : IcelakeClientProc<"icelake-client">;
|
|
|
|
|
|
|
|
|
|
class IcelakeServerProc<string Name> : ProcModel<Name, SkylakeServerModel,
|
|
|
|
|
ICLFeatures.Value, [
|
|
|
|
|
ProcIntelICX,
|
2018-05-08 14:47:36 +08:00
|
|
|
FeaturePCONFIG,
|
2018-04-12 04:01:57 +08:00
|
|
|
FeatureWBNOINVD,
|
2018-04-11 02:59:13 +08:00
|
|
|
FeatureHasFastGather
|
|
|
|
|
]>;
|
|
|
|
|
def : IcelakeServerProc<"icelake-server">;
|
2017-11-19 09:12:00 +08:00
|
|
|
|
2014-12-09 18:58:36 +08:00
|
|
|
// AMD CPUs.
|
2014-07-21 22:54:21 +08:00
|
|
|
|
2016-03-23 19:13:54 +08:00
|
|
|
def : Proc<"k6", [FeatureX87, FeatureSlowUAMem16, FeatureMMX]>;
|
|
|
|
|
def : Proc<"k6-2", [FeatureX87, FeatureSlowUAMem16, Feature3DNow]>;
|
|
|
|
|
def : Proc<"k6-3", [FeatureX87, FeatureSlowUAMem16, Feature3DNow]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
|
|
|
|
|
foreach P = ["athlon", "athlon-tbird"] in {
|
2018-08-27 02:29:27 +08:00
|
|
|
def : Proc<P, [FeatureX87, FeatureSlowUAMem16, FeatureCMOV, Feature3DNowA,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL, FeatureSlowSHLD]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach P = ["athlon-4", "athlon-xp", "athlon-mp"] in {
|
2018-08-27 02:29:33 +08:00
|
|
|
def : Proc<P, [FeatureX87, FeatureSlowUAMem16, FeatureCMOV, FeatureSSE1,
|
2018-01-11 06:07:16 +08:00
|
|
|
Feature3DNowA, FeatureFXSR, FeatureNOPL, FeatureSlowSHLD]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach P = ["k8", "opteron", "athlon64", "athlon-fx"] in {
|
|
|
|
|
def : Proc<P, [FeatureX87, FeatureSlowUAMem16, FeatureSSE2, Feature3DNowA,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureFXSR, FeatureNOPL, Feature64Bit, FeatureSlowSHLD,
|
|
|
|
|
FeatureCMOV]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach P = ["k8-sse3", "opteron-sse3", "athlon64-sse3"] in {
|
|
|
|
|
def : Proc<P, [FeatureX87, FeatureSlowUAMem16, FeatureSSE3, Feature3DNowA,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureFXSR, FeatureNOPL, FeatureCMPXCHG16B, FeatureSlowSHLD,
|
2018-08-30 14:01:05 +08:00
|
|
|
FeatureCMOV, Feature64Bit]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach P = ["amdfam10", "barcelona"] in {
|
|
|
|
|
def : Proc<P, [FeatureX87, FeatureSSE4A, Feature3DNowA, FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL, FeatureCMPXCHG16B, FeatureLZCNT, FeaturePOPCNT,
|
2018-08-30 14:01:05 +08:00
|
|
|
FeatureSlowSHLD, FeatureLAHFSAHF, FeatureCMOV, Feature64Bit]>;
|
2017-11-02 06:15:49 +08:00
|
|
|
}
|
2015-08-22 04:17:26 +08:00
|
|
|
|
2012-01-10 19:50:02 +08:00
|
|
|
// Bobcat
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : Proc<"btver1", [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSSE3,
|
|
|
|
|
FeatureSSE4A,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeatureLZCNT,
|
|
|
|
|
FeaturePOPCNT,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureSlowSHLD,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureFast15ByteNOP
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-09-10 04:07:07 +08:00
|
|
|
|
2013-05-03 18:20:08 +08:00
|
|
|
// Jaguar
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : ProcessorModel<"btver2", BtVer2Model, [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureAVX,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSSE4A,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureF16C,
|
|
|
|
|
FeatureMOVBE,
|
|
|
|
|
FeatureLZCNT,
|
2016-10-15 00:41:38 +08:00
|
|
|
FeatureFastLZCNT,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeaturePOPCNT,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVE,
|
|
|
|
|
FeatureXSAVEOPT,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureSlowSHLD,
|
2016-02-13 07:37:57 +08:00
|
|
|
FeatureLAHFSAHF,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureFast15ByteNOP,
|
2018-09-30 11:01:46 +08:00
|
|
|
FeatureFastBEXTR,
|
2017-03-03 17:03:24 +08:00
|
|
|
FeatureFastPartialYMMorZMMWrite
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-11-29 02:40:18 +08:00
|
|
|
|
2012-01-10 19:50:02 +08:00
|
|
|
// Bulldozer
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : Proc<"bdver1", [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureXOP,
|
|
|
|
|
FeatureFMA4,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureAVX,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSSE4A,
|
|
|
|
|
FeatureLZCNT,
|
|
|
|
|
FeaturePOPCNT,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVE,
|
2017-05-03 23:51:39 +08:00
|
|
|
FeatureLWP,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureSlowSHLD,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureFast11ByteNOP,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2013-05-03 18:20:08 +08:00
|
|
|
// Piledriver
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : Proc<"bdver2", [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureXOP,
|
|
|
|
|
FeatureFMA4,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureAVX,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSSE4A,
|
|
|
|
|
FeatureF16C,
|
|
|
|
|
FeatureLZCNT,
|
|
|
|
|
FeaturePOPCNT,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVE,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureTBM,
|
2017-05-03 23:51:39 +08:00
|
|
|
FeatureLWP,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureFMA,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureSlowSHLD,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureFast11ByteNOP,
|
2018-09-30 11:01:46 +08:00
|
|
|
FeatureFastBEXTR,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2013-11-04 18:29:20 +08:00
|
|
|
|
|
|
|
|
// Steamroller
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : Proc<"bdver3", [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureXOP,
|
|
|
|
|
FeatureFMA4,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureAVX,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSSE4A,
|
|
|
|
|
FeatureF16C,
|
|
|
|
|
FeatureLZCNT,
|
|
|
|
|
FeaturePOPCNT,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVE,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureTBM,
|
2017-05-03 23:51:39 +08:00
|
|
|
FeatureLWP,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureFMA,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVEOPT,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureSlowSHLD,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureFSGSBase,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureLAHFSAHF,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureFast11ByteNOP,
|
2018-09-30 11:01:46 +08:00
|
|
|
FeatureFastBEXTR,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2013-11-04 18:29:20 +08:00
|
|
|
|
2014-05-02 23:47:07 +08:00
|
|
|
// Excavator
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
def : Proc<"bdver4", [
|
2016-03-23 19:13:54 +08:00
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureAVX2,
|
2015-10-16 14:03:09 +08:00
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureXOP,
|
|
|
|
|
FeatureFMA4,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeatureF16C,
|
|
|
|
|
FeatureLZCNT,
|
|
|
|
|
FeaturePOPCNT,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVE,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureBMI2,
|
|
|
|
|
FeatureTBM,
|
2017-05-03 23:51:39 +08:00
|
|
|
FeatureLWP,
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
FeatureFMA,
|
2015-10-14 13:37:38 +08:00
|
|
|
FeatureXSAVEOPT,
|
2016-07-25 00:00:53 +08:00
|
|
|
FeatureSlowSHLD,
|
2015-12-05 07:00:33 +08:00
|
|
|
FeatureFSGSBase,
|
2016-05-18 19:59:12 +08:00
|
|
|
FeatureLAHFSAHF,
|
2018-09-30 11:01:46 +08:00
|
|
|
FeatureFastBEXTR,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureFast11ByteNOP,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureMWAITX,
|
|
|
|
|
FeatureMacroFusion
|
Move the MMX subtarget feature out of the SSE set of features and into
its own variable.
This is needed so that we can explicitly turn off MMX without turning
off SSE and also so that we can diagnose feature set incompatibilities
that involve MMX without SSE.
Rationale:
// sse3
__m128d test_mm_addsub_pd(__m128d A, __m128d B) {
return _mm_addsub_pd(A, B);
}
// mmx
void shift(__m64 a, __m64 b, int c) {
_mm_slli_pi16(a, c);
_mm_slli_pi32(a, c);
_mm_slli_si64(a, c);
_mm_srli_pi16(a, c);
_mm_srli_pi32(a, c);
_mm_srli_si64(a, c);
_mm_srai_pi16(a, c);
_mm_srai_pi32(a, c);
}
clang -msse3 -mno-mmx file.c -c
For this code we should be able to explicitly turn off MMX
without affecting the compilation of the SSE3 function and then
diagnose and error on compiling the MMX function.
This matches the existing gcc behavior and follows the spirit of
the SSE/MMX separation in llvm where we can (and do) turn off
MMX code generation except in the presence of intrinsics.
Updated a couple of tests, but primarily tested with a couple of tests
for turning on only mmx and only sse.
This is paired with a patch to clang to take advantage of this behavior.
llvm-svn: 249731
2015-10-09 04:10:06 +08:00
|
|
|
]>;
|
2014-05-02 23:47:07 +08:00
|
|
|
|
2017-07-19 10:45:14 +08:00
|
|
|
// Znver1
|
|
|
|
|
def: ProcessorModel<"znver1", Znver1Model, [
|
2017-01-10 14:01:16 +08:00
|
|
|
FeatureADX,
|
|
|
|
|
FeatureAES,
|
|
|
|
|
FeatureAVX2,
|
|
|
|
|
FeatureBMI,
|
|
|
|
|
FeatureBMI2,
|
|
|
|
|
FeatureCLFLUSHOPT,
|
2017-02-09 12:27:34 +08:00
|
|
|
FeatureCLZERO,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
2018-08-30 14:01:05 +08:00
|
|
|
Feature64Bit,
|
2017-01-10 14:01:16 +08:00
|
|
|
FeatureCMPXCHG16B,
|
|
|
|
|
FeatureF16C,
|
|
|
|
|
FeatureFMA,
|
|
|
|
|
FeatureFSGSBase,
|
|
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2017-01-10 14:01:16 +08:00
|
|
|
FeatureFastLZCNT,
|
|
|
|
|
FeatureLAHFSAHF,
|
|
|
|
|
FeatureLZCNT,
|
2018-09-30 11:01:46 +08:00
|
|
|
FeatureFastBEXTR,
|
2018-01-30 05:24:31 +08:00
|
|
|
FeatureFast15ByteNOP,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureMacroFusion,
|
2017-01-10 14:01:16 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureMOVBE,
|
|
|
|
|
FeatureMWAITX,
|
|
|
|
|
FeaturePCLMUL,
|
|
|
|
|
FeaturePOPCNT,
|
|
|
|
|
FeaturePRFCHW,
|
|
|
|
|
FeatureRDRAND,
|
|
|
|
|
FeatureRDSEED,
|
|
|
|
|
FeatureSHA,
|
|
|
|
|
FeatureSSE4A,
|
|
|
|
|
FeatureSlowSHLD,
|
|
|
|
|
FeatureX87,
|
|
|
|
|
FeatureXSAVE,
|
|
|
|
|
FeatureXSAVEC,
|
|
|
|
|
FeatureXSAVEOPT,
|
|
|
|
|
FeatureXSAVES]>;
|
|
|
|
|
|
2016-03-23 19:13:54 +08:00
|
|
|
def : Proc<"geode", [FeatureX87, FeatureSlowUAMem16, Feature3DNowA]>;
|
2006-10-06 17:17:41 +08:00
|
|
|
|
2016-03-23 19:13:54 +08:00
|
|
|
def : Proc<"winchip-c6", [FeatureX87, FeatureSlowUAMem16, FeatureMMX]>;
|
|
|
|
|
def : Proc<"winchip2", [FeatureX87, FeatureSlowUAMem16, Feature3DNow]>;
|
|
|
|
|
def : Proc<"c3", [FeatureX87, FeatureSlowUAMem16, Feature3DNow]>;
|
|
|
|
|
def : Proc<"c3-2", [FeatureX87, FeatureSlowUAMem16, FeatureMMX,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureSSE1, FeatureFXSR, FeatureCMOV]>;
|
2006-10-06 17:17:41 +08:00
|
|
|
|
2014-05-08 01:37:03 +08:00
|
|
|
// We also provide a generic 64-bit specific x86 processor model which tries to
|
|
|
|
|
// be good for modern chips without enabling instruction set encodings past the
|
|
|
|
|
// basic SSE2 and 64-bit ones. It disables slow things from any mainstream and
|
|
|
|
|
// modern 64-bit x86 chip, and enables features that are generally beneficial.
|
2014-12-04 13:20:33 +08:00
|
|
|
//
|
2014-05-08 01:37:03 +08: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.
|
2017-08-21 16:45:22 +08:00
|
|
|
def : ProcessorModel<"x86-64", SandyBridgeModel, [
|
|
|
|
|
FeatureX87,
|
2018-08-27 02:29:33 +08:00
|
|
|
FeatureCMOV,
|
2017-08-21 16:45:22 +08:00
|
|
|
FeatureMMX,
|
|
|
|
|
FeatureSSE2,
|
|
|
|
|
FeatureFXSR,
|
2018-01-11 06:07:16 +08:00
|
|
|
FeatureNOPL,
|
2017-08-21 16:45:22 +08:00
|
|
|
Feature64Bit,
|
|
|
|
|
FeatureSlow3OpsLEA,
|
2017-08-30 12:34:48 +08:00
|
|
|
FeatureSlowIncDec,
|
|
|
|
|
FeatureMacroFusion
|
2017-08-21 16:45:22 +08:00
|
|
|
]>;
|
2014-05-08 01:37:03 +08:00
|
|
|
|
2007-02-27 02:17:14 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Calling Conventions
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "X86CallingConv.td"
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
2010-10-30 21:48:28 +08:00
|
|
|
// Assembly Parser
|
2007-02-27 02:17:14 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2012-01-10 03:13:28 +08:00
|
|
|
def ATTAsmParserVariant : AsmParserVariant {
|
2009-07-29 08:02:19 +08:00
|
|
|
int Variant = 0;
|
2009-08-12 04:59:47 +08:00
|
|
|
|
2013-04-19 06:35:36 +08:00
|
|
|
// Variant name.
|
|
|
|
|
string Name = "att";
|
|
|
|
|
|
2009-08-12 04:59:47 +08:00
|
|
|
// Discard comments in assembly strings.
|
|
|
|
|
string CommentDelimiter = "#";
|
|
|
|
|
|
|
|
|
|
// Recognize hard coded registers.
|
|
|
|
|
string RegisterPrefix = "%";
|
2009-07-29 08:02:19 +08:00
|
|
|
}
|
|
|
|
|
|
2012-01-11 01:51:54 +08:00
|
|
|
def IntelAsmParserVariant : AsmParserVariant {
|
|
|
|
|
int Variant = 1;
|
|
|
|
|
|
2013-04-19 06:35:36 +08:00
|
|
|
// Variant name.
|
|
|
|
|
string Name = "intel";
|
|
|
|
|
|
2012-01-11 01:51:54 +08:00
|
|
|
// Discard comments in assembly strings.
|
|
|
|
|
string CommentDelimiter = ";";
|
|
|
|
|
|
|
|
|
|
// Recognize hard coded registers.
|
|
|
|
|
string RegisterPrefix = "";
|
|
|
|
|
}
|
|
|
|
|
|
2010-10-30 21:48:28 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Assembly Printers
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
2004-10-04 04:36:57 +08:00
|
|
|
// The X86 target supports two different syntaxes for emitting machine code.
|
|
|
|
|
// This is controlled by the -x86-asm-syntax={att|intel}
|
|
|
|
|
def ATTAsmWriter : AsmWriter {
|
2009-09-14 03:30:11 +08:00
|
|
|
string AsmWriterClassName = "ATTInstPrinter";
|
2004-10-04 04:36:57 +08:00
|
|
|
int Variant = 0;
|
|
|
|
|
}
|
|
|
|
|
def IntelAsmWriter : AsmWriter {
|
2009-09-20 15:47:59 +08:00
|
|
|
string AsmWriterClassName = "IntelInstPrinter";
|
2004-10-04 04:36:57 +08:00
|
|
|
int Variant = 1;
|
|
|
|
|
}
|
|
|
|
|
|
2003-08-04 02:19:37 +08:00
|
|
|
def X86 : Target {
|
|
|
|
|
// Information about the instructions...
|
2003-08-04 12:59:56 +08:00
|
|
|
let InstructionSet = X86InstrInfo;
|
2012-01-11 01:51:54 +08:00
|
|
|
let AssemblyParserVariants = [ATTAsmParserVariant, IntelAsmParserVariant];
|
2004-10-04 04:36:57 +08:00
|
|
|
let AssemblyWriters = [ATTAsmWriter, IntelAsmWriter];
|
[MachineOperand][Target] MachineOperand::isRenamable semantics changes
Summary:
Add a target option AllowRegisterRenaming that is used to opt in to
post-register-allocation renaming of registers. This is set to 0 by
default, which causes the hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq
fields of all opcodes to be set to 1, causing
MachineOperand::isRenamable to always return false.
Set the AllowRegisterRenaming flag to 1 for all in-tree targets that
have lit tests that were effected by enabling COPY forwarding in
MachineCopyPropagation (AArch64, AMDGPU, ARM, Hexagon, Mips, PowerPC,
RISCV, Sparc, SystemZ and X86).
Add some more comments describing the semantics of the
MachineOperand::isRenamable function and how it is set and maintained.
Change isRenamable to check the operand's opcode
hasExtraSrcRegAllocReq/hasExtraDstRegAllocReq bit directly instead of
relying on it being consistently reflected in the IsRenamable bit
setting.
Clear the IsRenamable bit when changing an operand's register value.
Remove target code that was clearing the IsRenamable bit when changing
registers/opcodes now that this is done conservatively by default.
Change setting of hasExtraSrcRegAllocReq in AMDGPU target to be done in
one place covering all opcodes that have constant pipe read limit
restrictions.
Reviewers: qcolombet, MatzeB
Subscribers: aemerson, arsenm, jyknight, mcrosier, sdardis, nhaehnle, javed.absar, tpr, arichardson, kristof.beyls, kbarton, fedor.sergeev, asb, rbar, johnrusso, simoncook, jordy.potman.lists, apazos, sabuasal, niosHD, escha, nemanjai, llvm-commits
Differential Revision: https://reviews.llvm.org/D43042
llvm-svn: 325931
2018-02-24 02:25:08 +08:00
|
|
|
let AllowRegisterRenaming = 1;
|
2003-08-04 02:19:37 +08:00
|
|
|
}
|
2018-04-10 16:16:37 +08:00
|
|
|
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
// Pfm Counters
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
include "X86PfmCounters.td"
|