| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This patch adds -mrdpid/-mno-rdpid and the rdpid intrinsic. The corresponding LLVM commit has already been made.
Reviewers: RKSimon, spatel, zvi, AndreiGrischenko
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42272
llvm-svn: 323047
|
|
|
|
|
|
| |
preprocessor with the other __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* defines. NFC
llvm-svn: 323046
|
|
|
|
|
|
|
|
|
|
| |
the backend.
Similarly, make -mno-fma and -mno-f16c imply -mno-avx512f.
Withou this "-mno-sse -mavx512f" ends up with avx512f being enabled in the frontend but disabled in the backend.
llvm-svn: 322245
|
|
|
|
|
|
|
|
|
|
| |
Cf-protection is a target independent flag that instructs the back-end to instrument control flow mechanisms like: Branch, Return, etc.
For example in X86 this flag will be used to instrument Indirect Branch Tracking instructions.
Differential Revision: https://reviews.llvm.org/D40478
Change-Id: I5126e766c0e6b84118cae0ee8a20fe78cc373dea
llvm-svn: 322063
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
GCC's attribute 'target', in addition to being an optimization hint,
also allows function multiversioning. We currently have the former
implemented, this is the latter's implementation.
This works by enabling functions with the same name/signature to coexist,
so that they can all be emitted. Multiversion state is stored in the
FunctionDecl itself, and SemaDecl manages the definitions.
Note that it ends up having to permit redefinition of functions so
that they can all be emitted. Additionally, all versions of the function
must be emitted, so this also manages that.
Note that this includes some additional rules that GCC does not, since
defining something as a MultiVersion function after a usage has been made illegal.
The only 'history rewriting' that happens is if a function is emitted before
it has been converted to a multiversion'ed function, at which point its name
needs to be changed.
Function templates and virtual functions are NOT yet supported (not supported
in GCC either).
Additionally, constructors/destructors are disallowed, but the former is
planned.
llvm-svn: 322028
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
icelake or CLWB on cannonlake."
I based that commit on what was in Intel's public documentation here https://software.intel.com/sites/default/files/managed/c5/15/architecture-instruction-set-extensions-programming-reference.pdf
Which specifically said CLWB wasn't until Icelake.
But I've since cross checked with SDE and it thinks these features exist on CNL and ICL. So now I don't know what to believe.
I've added test coverage of the current behavior as part of the revert so at least now have proof of what we're doing.
llvm-svn: 321547
|
|
|
|
|
|
|
|
| |
cannonlake.
We have cannonlake and icelake inheriting from skylake server in a switch using fallthroughs. But they aren't perfect supersets of skylake server.
llvm-svn: 321504
|
|
|
|
|
|
| |
Per table 1-1 of the October 2017 edition of Intel® Architecture Instruction Set Extensions and Future Features Programming Reference
llvm-svn: 321502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added vbmi2 feature recognition
added intrinsics support for vbmi2 instructions
_mm[128,256,512]_mask[z]_compress_epi[16,32]
_mm[128,256,512]_mask_compressstoreu_epi[16,32]
_mm[128,256,512]_mask[z]_expand_epi[16,32]
_mm[128,256,512]_mask[z]_expandloadu_epi[16,32]
_mm[128,256,512]_mask[z]_sh[l,r]di_epi[16,32,64]
_mm[128,256,512]_mask_sh[l,r]dv_epi[16,32,64]
matching a similar work on the backend (D40206)
Differential Revision: https://reviews.llvm.org/D41557
llvm-svn: 321487
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added vnni feature recognition
added intrinsics support for VNNI instructions
_mm256_mask_dpbusd_epi32
_mm256_maskz_dpbusd_epi32
_mm256_dpbusd_epi32
_mm256_mask_dpbusds_epi32
_mm256_maskz_dpbusds_epi32
_mm256_dpbusds_epi32
_mm256_mask_dpwssd_epi32
_mm256_maskz_dpwssd_epi32
_mm256_dpwssd_epi32
_mm256_mask_dpwssds_epi32
_mm256_maskz_dpwssds_epi32
_mm256_dpwssds_epi32
_mm128_mask_dpbusd_epi32
_mm128_maskz_dpbusd_epi32
_mm128_dpbusd_epi32
_mm128_mask_dpbusds_epi32
_mm128_maskz_dpbusds_epi32
_mm128_dpbusds_epi32
_mm128_mask_dpwssd_epi32
_mm128_maskz_dpwssd_epi32
_mm128_dpwssd_epi32
_mm128_mask_dpwssds_epi32
_mm128_maskz_dpwssds_epi32
_mm128_dpwssds_epi32
_mm512_mask_dpbusd_epi32
_mm512_maskz_dpbusd_epi32
_mm512_dpbusd_epi32
_mm512_mask_dpbusds_epi32
_mm512_maskz_dpbusds_epi32
_mm512_dpbusds_epi32
_mm512_mask_dpwssd_epi32
_mm512_maskz_dpwssd_epi32
_mm512_dpwssd_epi32
_mm512_mask_dpwssds_epi32
_mm512_maskz_dpwssds_epi32
_mm512_dpwssds_epi32
matching a similar work on the backend (D40208)
Differential Revision: https://reviews.llvm.org/D41558
llvm-svn: 321484
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added bitalg feature recognition
added intrinsics support for bitalg instructions
_mm512_popcnt_epi16
_mm512_mask_popcnt_epi16
_mm512_maskz_popcnt_epi16
_mm512_popcnt_epi8
_mm512_mask_popcnt_epi8
_mm512_maskz_popcnt_epi8
_mm512_mask_bitshuffle_epi64_mask
_mm512_bitshuffle_epi64_mask
_mm256_popcnt_epi16
_mm256_mask_popcnt_epi16
_mm256_maskz_popcnt_epi16
_mm128_popcnt_epi16
_mm128_mask_popcnt_epi16
_mm128_maskz_popcnt_epi16
_mm256_popcnt_epi8
_mm256_mask_popcnt_epi8
_mm256_maskz_popcnt_epi8
_mm128_popcnt_epi8
_mm128_mask_popcnt_epi8
_mm128_maskz_popcnt_epi8
_mm256_mask_bitshuffle_epi32_mask
_mm256_bitshuffle_epi32_mask
_mm128_mask_bitshuffle_epi16_mask
_mm128_bitshuffle_epi16_mask
matching a similar work on the backend (D40222)
Differential Revision: https://reviews.llvm.org/D41564
llvm-svn: 321483
|
|
|
|
|
|
|
|
|
|
|
| |
added vpclmulqdq feature recognition
added intrinsics support for vpclmulqdq instructions
_mm256_clmulepi64_epi128
_mm512_clmulepi64_epi128
matching a similar work on the backend (D40101)
Differential Revision: https://reviews.llvm.org/D41573
llvm-svn: 321480
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added gfni feature recognition
added intrinsics support for gfni instructions
_mm_gf2p8affineinv_epi64_epi8
_mm_mask_gf2p8affineinv_epi64_epi8
_mm_maskz_gf2p8affineinv_epi64_epi8
_mm256_gf2p8affineinv_epi64_epi8
_mm256_mask_gf2p8affineinv_epi64_epi8
_mm256_maskz_gf2p8affineinv_epi64_epi8
_mm512_gf2p8affineinv_epi64_epi8
_mm512_mask_gf2p8affineinv_epi64_epi8
_mm512_maskz_gf2p8affineinv_epi64_epi8
_mm_gf2p8affine_epi64_epi8
_mm_mask_gf2p8affine_epi64_epi8
_mm_maskz_gf2p8affine_epi64_epi8
_mm256_gf2p8affine_epi64_epi8
_mm256_mask_gf2p8affine_epi64_epi8
_mm256_maskz_gf2p8affine_epi64_epi8
_mm512_gf2p8affine_epi64_epi8
_mm512_mask_gf2p8affine_epi64_epi8
_mm512_maskz_gf2p8affine_epi64_epi8
_mm_gf2p8mul_epi8
_mm_mask_gf2p8mul_epi8
_mm_maskz_gf2p8mul_epi8
_mm256_gf2p8mul_epi8
_mm256_mask_gf2p8mul_epi8
_mm256_maskz_gf2p8mul_epi8
_mm512_gf2p8mul_epi8
_mm512_mask_gf2p8mul_epi8
_mm512_maskz_gf2p8mul_epi8
matching a similar work on the backend (D40373)
Differential Revision: https://reviews.llvm.org/D41582
llvm-svn: 321477
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
added vaes feature recognition
added intrinsics support for vaes instructions, matching a similar work on the backend (D40078)
_mm256_aesenc_epi128
_mm512_aesenc_epi128
_mm256_aesenclast_epi128
_mm512_aesenclast_epi128
_mm256_aesdec_epi128
_mm512_aesdec_epi128
_mm256_aesdeclast_epi128
_mm512_aesdeclast_epi128
llvm-svn: 321474
|
|
|
|
| |
llvm-svn: 321341
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://bugs.llvm.org/show_bug.cgi?id=35721 reports that x86intrin.h
is issuing a few warnings. This is because attribute target is using
isValidFeatureName for its source. It was also discovered that two of
these were missing from hasFeature.
Additionally, shstk is and ibu are reordered alphabetically, as came
up during code review.
llvm-svn: 321324
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tracking support (Clang side)
Shadow stack solution introduces a new stack for return addresses only.
The stack has a Shadow Stack Pointer (SSP) that points to the last address to which we expect to return.
If we return to a different address an exception is triggered.
This patch includes shadow stack intrinsics as well as the corresponding CET header.
It includes CET clang flags for shadow stack and Indirect Branch Tracking.
For more information, please see the following:
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
Differential Revision: https://reviews.llvm.org/D40224
Change-Id: I79ad0925a028bbc94c8ecad75f6daa2f214171f1
llvm-svn: 318995
|
|
|
|
| |
llvm-svn: 318815
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D38445
llvm-svn: 318739
|
|
|
|
|
|
| |
The correct spelling is '3dnow' which is already in the list.
llvm-svn: 318716
|
|
|
|
| |
llvm-svn: 318617
|
|
|
|
|
|
| |
This is the resolution we came to in D38824.
llvm-svn: 318616
|
|
|
|
|
|
|
|
|
|
|
| |
A first step toward removing the repetition of
features/CPU info in the x86 target info, this
patch pulls all the processor information out into
its own .def file.
Differential Revision: https://reviews.llvm.org/D40093
llvm-svn: 318343
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM exposes a file in the backend (X86TargetParser.def) that
contains information about the correct list of CpuIs values.
This patch removes 2 of the copied and pasted versions of this
list from clang and instead includes the data from the .def file.
Differential Revision: https://reviews.llvm.org/D40054
llvm-svn: 318234
|
|
|
|
|
|
|
|
| |
These were missed in SVN r316783, which broke compiling mingw-w64 CRT.
Differential Revision: https://reviews.llvm.org/D39631
llvm-svn: 317504
|
|
|
|
|
|
| |
match GCC
llvm-svn: 317069
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Craig noticed that CodeGen wasn't properly ignoring the
values sent to the target attribute. This patch ignores
them.
This patch also sets the 'default' for this checking to
'supported', since only X86 has implemented the support
for checking valid CPU names and Feature Names.
One test was changed to i686, since it uses a lakemont,
which would otherwise be prohibited in x86_64.
Differential Revision: https://reviews.llvm.org/D39357
llvm-svn: 316783
|
|
|
|
|
|
|
|
|
| |
These are not valid values for this, and are pretty
non-sensical, since LLVM doesn't understand them.
Differential Revision: https://reviews.llvm.org/D39378
llvm-svn: 316781
|
|
|
|
|
|
| |
sse4 is valid for target attribute and functions as an alias of sse4.2.
llvm-svn: 316718
|
|
|
|
|
|
|
|
| |
I think the only reason they are different is because we don't set tune_i686 for -march=i686 to match GCC. But GCC 4.9.0 seems to have changed this behavior and they do set it now. So I think they can aliases now.
Differential Revision: https://reviews.llvm.org/D39349
llvm-svn: 316712
|
|
|
|
|
|
| |
As indicated by Table 1-1 in Intel Architecture Instruction Set Extensions and Future Features Programming Reference from October 2017.
llvm-svn: 316593
|
|
|
|
|
|
|
|
| |
Preparing to do a refactor of CPU/feature checking, this
patch pulls the one CPU implementation from the .h file
to the .cpp file.
llvm-svn: 316338
|
|
|
|
|
|
|
|
| |
This adds support Knights Mill CPU. Preprocessor defines match gcc's implementation.
Differential Revision: https://reviews.llvm.org/D38813
llvm-svn: 315723
|
|
|
|
|
|
| |
The compiler-rt implementation already supported it, it just wasn't exposed.
llvm-svn: 315517
|
|
|
|
|
| |
Change-Id: I6c22478d16b8e02ce60dae2f8c80d43bc5ab3a9c
llvm-svn: 314104
|
|
|
|
|
|
|
|
| |
This arranges more of the Intel and AMD CPUs into fallthrough positions based on their features. We may be able to merge this new AMD set with the BTVER or BDVER sets but I didn't look that closely.
Differential Revision: https://reviews.llvm.org/D37941
llvm-svn: 313497
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
For a lot of older CPUs we have a 1:1 mapping between CPU name and enum name. But many of them are effectively aliases of each other and as a result are always repeated together at every usage
This patch removes most of the duplication. It also uses StringSwitch::Cases to make the many to one mapping in the StringSwitch more obvious.
Reviewers: RKSimon, spatel, zvi, igorb
Reviewed By: RKSimon
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37938
llvm-svn: 313462
|
|
|
|
|
|
|
|
|
|
| |
This patch is intended to enable the use of basic double letter constraints used in GCC extended inline asm {Yi Y2 Yz Y0 Ym Yt}.
Supersedes D35205
llvm counterpart: D36369
Differential Revision: https://reviews.llvm.org/D36371
llvm-svn: 311643
|
|
|
|
|
|
|
|
| |
This patch adds support for __builtin_cpu_is. I've tried to match the strings supported to the latest version of gcc.
Differential Revision: https://reviews.llvm.org/D35449
llvm-svn: 310657
|
|
|
|
|
|
| |
They still need to be implemented in the intrinsics, the command line, and the backend. But this change isn't dependent on any of that and resolves a TODO.
llvm-svn: 310386
|
|
|
|
|
|
|
|
| |
Allows the incorporation of legit (x86) Debug Regs within inline asm stataements
Differential Revision: https://reviews.llvm.org/D36074
llvm-svn: 309672
|
|
|
|
|
|
|
|
| |
Allows the incorporation of legit (x86) Control Regs within inline asm stataements
Differential Revision: https://reviews.llvm.org/D35903
llvm-svn: 309508
|
|
Targets.cpp is getting unwieldy, and even minor changes cause the entire thing
to cause recompilation for everyone. This patch bites the bullet and breaks
it up into a number of files.
I tended to keep function definitions in the class declaration unless it
caused additional includes to be necessary. In those cases, I pulled it
over into the .cpp file. Content is copy/paste for the most part,
besides includes/format/etc.
Differential Revision: https://reviews.llvm.org/D35701
llvm-svn: 308791
|