| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D40985
llvm-svn: 320195
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Shadow stack solution introduces a new stack for return addresses only.
The HW has a Shadow Stack Pointer (SSP) that points to the next return address.
If we return to a different address, an exception is triggered.
The shadow stack is managed using a series of intrinsics that are introduced in this patch as well as the new register (SSP).
The intrinsics are mapped to new instruction set that implements CET mechanism.
The patch also includes initial infrastructure support for IBT.
For more information, please see the following:
https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf
Differential Revision: https://reviews.llvm.org/D40223
Change-Id: I4daa1f27e88176be79a4ac3b4cd26a459e88fed4
llvm-svn: 318996
|
|
|
|
|
|
|
|
|
|
| |
galois field arithmetic (GF(2^8)) insns:
gf2p8affineinvqb
gf2p8affineqb
gf2p8mulb
Differential Revision: https://reviews.llvm.org/D40373
llvm-svn: 318993
|
|
|
|
|
|
|
|
| |
shared by Host.cpp to a .def file and TargetParser.h so clang can make use of it.
Since we keep Host.cpp and compiler-rt relatively in sync, clang can use this information as a proxy.
llvm-svn: 318814
|
|
|
|
| |
llvm-svn: 318792
|
|
|
|
|
|
|
| |
vpopcnt{b,w}
Differential Revision: https://reviews.llvm.org/D40213
llvm-svn: 318748
|
|
|
|
|
|
|
|
|
| |
Introducing Vector Neural Network Instructions, consisting of:
vpdpbusd{s}
vpdpwssd{s}
Differential Revision: https://reviews.llvm.org/D40208
llvm-svn: 318746
|
|
|
|
|
|
|
|
|
|
|
| |
introducing vbmi2, consisting of
vpcompress{b,w}
vpexpand{b,w}
vpsh{l,r}d{w,d,q}
vpsh{l,r}dv{w,d,q}
Differential Revision: https://reviews.llvm.org/D40206
llvm-svn: 318745
|
|
|
|
|
|
|
| |
an icelake promotion of pclmulqdq
Differential Revision: https://reviews.llvm.org/D40101
llvm-svn: 318741
|
|
|
|
|
|
|
| |
an icelake promotion of AES
Differential Revision: https://reviews.llvm.org/D40078
llvm-svn: 318740
|
|
|
|
|
|
|
|
| |
getX86CpuIDAndInfoEx.
This leaf doesn't take an additional argument.
llvm-svn: 318634
|
|
|
|
|
|
| |
keep the bits in order per register and encourage future additions to be in order too.
llvm-svn: 318633
|
|
|
|
| |
llvm-svn: 318331
|
|
|
|
|
|
| |
uses Goldmont.
llvm-svn: 318271
|
|
|
|
|
|
| |
This adds an explicit model number check and fallback path to the unknown family 6 detection.
llvm-svn: 318270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
I want to leverage this to clean up some of the code in clang. This will allow us to simplify D39521 which was trying to do some of the same.
If we accurately keep the code in Host.cpp synced with new CPUs added to compile-rt/libgcc we should be able to use this file as a proxy for what's implemented in the libraries.
The entries for the CPUs recognized by the libraries use separate macros that define additional parameters like the name for __builtin_cpu_is and an alias string for the couple cases where __builtin_cpu_is accepts two different names.
All of the macros contain an ARCHNAME that is usually the same as the __builtin_cpu_is string, but sometimes isn't. This represents the name recognized by X86.td and -march.
I'm following the precedent set by ARM and AArch64 and adding this information to lib/Support/TargetParser.cpp
Reviewers: erichkeane, echristo, asbirlea
Reviewed By: echristo
Subscribers: llvm-commits, aemerson, kristof.beyls
Differential Revision: https://reviews.llvm.org/D39782
llvm-svn: 317900
|
|
|
|
|
|
|
|
|
|
| |
subtypes in getHostCPUName. NFCI
This removes the athlon type and simplifies the string decoding. We only really need these type/subtype breaks where we need to match libgcc/compiler-rt and these CPUs aren't part of that.
I'm looking into moving some of this information to a .def file to share with clang's __builtin_cpu_is handling. And while these CPUs aren't part of that the less lines I have to deal with in the .def file the better.
llvm-svn: 317354
|
|
|
|
| |
llvm-svn: 317341
|
|
|
|
|
|
|
|
| |
flags. Don't use 'x86-64' ever.
'x86-64' has started to reflect a sort of generic tuning flag for more modern 64-bit CPUs. We probably shouldn't be using it as the name of an unidentifiable pentium4. So use nocona for all 64-bit pentium4s instead.
llvm-svn: 317230
|
|
|
|
|
|
|
|
| |
CPUs in family 6 that has 64-bit support but not any newer SSE features. Use 'core2' instead
We know that's the earliest CPU with 64-bit support. x86-64 has taken on a role of representing a more modern 64-bit CPU so we probably shouldn't be using that when we can't identify things.
llvm-svn: 317229
|
|
|
|
|
|
| |
This just provided a bunch of comments to read and not much else.
llvm-svn: 317185
|
|
|
|
|
|
| |
Rather than looking at model numbers just check for the mmx feature flag. While there promote INTEL_PENTIUM_MMX to a CPU type instead of a subtype so that we don't have weird type with only one subtype.
llvm-svn: 317184
|
|
|
|
|
|
|
|
| |
This adds Intel's Knights Mill CPU to valid CPU names for the backend. For now its an alias of "knl", but ultimately we need to support AVX5124FMAPS and AVX5124VNNIW instruction sets for it.
Differential Revision: https://reviews.llvm.org/D38811
llvm-svn: 315722
|
|
|
|
| |
llvm-svn: 314105
|
|
|
|
|
|
| |
This returns "falkor" for Falkor CPU.
llvm-svn: 313998
|
|
|
|
|
|
|
|
|
| |
This returns "cortex-a73" for second-generation Kryo; not precisely
correct, but close enough.
Differential Revision: https://reviews.llvm.org/D37724
llvm-svn: 313200
|
|
|
|
|
| |
Signed-off-by: Yonghong Song <yhs@fb.com>
llvm-svn: 311567
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-mcpu=# will support:
. generic: the default insn set
. v1: insn set version 1, the same as generic
. v2: insn set version 2, version 1 + additional jmp insns
. probe: the compiler will probe the underlying kernel to
decide proper version of insn set.
We did not not use -mcpu=native since llc/llvm will interpret -mcpu=native
as the underlying hardware architecture regardless of -march value.
Currently, only x86_64 supports -mcpu=probe. Other architecture will
silently revert to "generic".
Also added -mcpu=help to print available cpu parameters.
llvm will print out the information only if there are at least one
cpu and at least one feature. Add an unused dummy feature to
enable the printout.
Examples for usage:
$ llc -march=bpf -mcpu=v1 -filetype=asm t.ll
$ llc -march=bpf -mcpu=v2 -filetype=asm t.ll
$ llc -march=bpf -mcpu=generic -filetype=asm t.ll
$ llc -march=bpf -mcpu=probe -filetype=asm t.ll
$ llc -march=bpf -mcpu=v3 -filetype=asm t.ll
'v3' is not a recognized processor for this target (ignoring processor)
...
$ llc -march=bpf -mcpu=help -filetype=asm t.ll
Available CPUs for this target:
generic - Select the generic processor.
probe - Select the probe processor.
v1 - Select the v1 processor.
v2 - Select the v2 processor.
Available features for this target:
dummy - unused feature.
Use +feature to enable a feature, or -feature to disable it.
For example, llc -mcpu=mycpu -mattr=+feature1,-feature2
...
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Yonghong Song <yhs@fb.com>
Acked-by: Alexei Starovoitov <ast@kernel.org>
llvm-svn: 311522
|
|
|
|
|
|
|
|
| |
This patch improves our guessing of unknown Intel CPUs to support Goldmont and skylake-avx512.
Differential Revision: https://reviews.llvm.org/D35161
llvm-svn: 309246
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch series adds support for the IBM z14 processor. This part includes:
- Basic support for the new processor and its features.
- Support for new instructions (except vector 32-bit float and 128-bit float).
- CodeGen for new instructions, including new LLVM intrinsics.
- Scheduler description for the new processor.
- Detection of z14 as host processor.
Support for the new 32-bit vector float and 128-bit vector float
instructions is provided by separate patches.
llvm-svn: 308194
|
|
|
|
|
|
|
|
|
|
| |
getHostCPUName/getHostCPUFeatures for 32-bit builds too.
We're already using it in 64-bit builds because 64-bit MSVC doesn't support inline assembly.
As far as I know we were using inline assembly because at the time the code was added we had to support MSVC 2008 pre-SP1 while the intrinsic was added to MSVC in SP1. Now that we don't have to support that we should be able to just use the intrinsic.
llvm-svn: 308163
|
|
|
|
|
|
| |
As far as I can tell we can simply distinguish based on features rather than model number. Many of the strings we were previously using are treated the same by the backend.
llvm-svn: 307884
|
|
|
|
|
|
|
|
| |
enum in libgcc and soon compiler-rt.
This adds all the feature bits libgcc has. They will soon be added to compiler-rt as well. This adds a second 32 bit feature variable to hold the bits that are needed by getHostCPUName that are not in libgcc. libgcc had already used 31 of the 32 bits in the existing variable and we needed 3 bits so at minimum 2 bits would spill over. I chose to move all 3.
llvm-svn: 307758
|
|
|
|
|
|
|
|
| |
with the version proposed to for compiler-rt's cpu_model.c
This keeps the starting entries in the enums in sync with what's in gcc and in review D35214 for compiler-rt.
llvm-svn: 307757
|
|
|
|
| |
llvm-svn: 307756
|
|
|
|
|
|
| |
The x86 backend doesn't distinguish.
llvm-svn: 307755
|
|
|
|
| |
llvm-svn: 307522
|
|
|
|
|
|
|
|
|
|
| |
past behavior of returning an unsupported indication to the caller instead.
These asserts could only occur if we fail to properly detect the compiler, but an assert is not a good way to do that because it doesn't work in release builds.
I wonder if we could use #error?
llvm-svn: 307520
|
|
|
|
|
|
|
|
| |
getHostCPUName.
Users of getHostCPUName should also use getHostCPUFeatures which will take care of making sure avx512 is disabled if the CPU doesn't support it. This is consistent with what we do for other CPUs.
llvm-svn: 307495
|
|
|
|
|
|
|
|
|
|
|
|
| |
based on features not being enabled.
The CPU name is really just used for scheduler and other microarchitectural optimizations. The feature flags should be determined by getHostCPUFeatures which should always be used with getHostCPUName. Trying to alter CPU name strings to control features just isn't practical.
Most of these types of things were removed from Intel CPUs a while ago.
This is part of my plan to bring compiler-rt's cpu_model.c file up to date with the equivalent functionality in libgcc. A lot of the code in that file is copied from Host.cpp and we want to keep them reasonably in sync.
llvm-svn: 307467
|
|
|
|
|
|
| |
According to wikipedia and some other googling suggests these should also be considered as BDVER4.
llvm-svn: 307466
|
|
|
|
| |
llvm-svn: 307465
|
|
|
|
|
|
| |
portion of Host.cpp.
llvm-svn: 307463
|
|
|
|
|
|
| |
We should make sure leaf 1 is available before accessing it. Same with leaf 0x80000001.
llvm-svn: 307462
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the system's version of macOS
sys::getProcessTriple returns LLVM_HOST_TRIPLE, whose system version might not
be the actual version of the system on which the compiler running. This commit
ensures that, for macOS, sys::getProcessTriple returns a triple with the
system's macOS version.
rdar://33177551
Differential Revision: https://reviews.llvm.org/D34446
llvm-svn: 307372
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
[LLVM SIDE]
Connecting the GoldMont processor to his feature.
Reviewers:
1. igorb
2. zvi
3. delena
4. RKSimon
5. craig.topper
Differential Revision: https://reviews.llvm.org/D34504
llvm-svn: 306658
|
|
|
|
| |
llvm-svn: 304086
|
|
|
|
|
|
|
|
|
| |
AVX512_VPOPCNTDQ is a new feature set that was published by Intel.
The patch represents the LLVM side of the addition of two new intrinsic based instructions (vpopcntd and vpopcntq).
Differential Revision: https://reviews.llvm.org/D33169
llvm-svn: 303858
|
|
|
|
|
|
|
|
|
|
| |
This patch adds support for the the LightWeight Profiling (LWP) instructions which are available on all AMD Bulldozer class CPUs (bdver1 to bdver4).
Reapplied - this time without changing line endings of existing files.
Differential Revision: https://reviews.llvm.org/D32769
llvm-svn: 302041
|
|
|
|
| |
llvm-svn: 302038
|