Three new instructions:
umonitor - Sets up a linear address range to be
monitored by hardware and activates the monitor.
The address range should be a writeback memory
caching type.
umwait - A hint that allows the processor to
stop instruction execution and enter an
implementation-dependent optimized state
until occurrence of a class of events.
tpause - Directs the processor to enter an
implementation-dependent optimized state
until the TSC reaches the value in EDX:EAX.
Also modifying the description of the mfence
instruction, as the rep prefix (0xF3) was allowed
before, which would conflict with umonitor during
disassembly.
Before:
$ echo 0xf3,0x0f,0xae,0xf0 | llvm-mc -disassemble
.text
mfence
After:
$ echo 0xf3,0x0f,0xae,0xf0 | llvm-mc -disassemble
.text
umonitor %rax
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45253
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@330462 91177308-0d34-0410-b5e6-96231b3b80d8
Hint to hardware to move the cache line containing the
address to a more distant level of the cache without
writing back to memory.
Reviewers: craig.topper, zvi
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D45256
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329992 91177308-0d34-0410-b5e6-96231b3b80d8
Similar to the wbinvd instruction, except this
one does not invalidate caches. Ring 0 only.
The encoding matches a wbinvd instruction with
an F3 prefix.
Reviewers: craig.topper, zvi, ashlykov
Reviewed By: craig.topper
Differential Revision: https://reviews.llvm.org/D43816
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@329847 91177308-0d34-0410-b5e6-96231b3b80d8
I think most of the Intel Core CPUs and recent AMD CPUs are unaffected. All the CPUs that have a "subtype" should work. The ones that were broken are the ones that are a "type" with no subtypes.
Fixes PR36619.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@326840 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: We probably mostly get this right due to family/model/stepping mapping to CPU names. But we should detect it explicitly.
Reviewers: RKSimon, echristo, dim, spatel
Reviewed By: dim
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D43418
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@325439 91177308-0d34-0410-b5e6-96231b3b80d8
This adds a new instrinsic to support the rdpid instruction. The implementation is a bit weird because the intrinsic is defined as always returning 32-bits, but the assembler support thinks the instruction produces a 64-bit register in 64-bit mode. But really it zeros the upper 32 bits. So I had to add separate patterns where 64-bit mode uses an extract_subreg.
Differential Revision: https://reviews.llvm.org/D42205
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@322910 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@318996 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317900 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317354 91177308-0d34-0410-b5e6-96231b3b80d8
'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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317230 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317229 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@317184 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315722 91177308-0d34-0410-b5e6-96231b3b80d8
-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>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311522 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308194 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@308163 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307884 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307758 91177308-0d34-0410-b5e6-96231b3b80d8
This keeps the starting entries in the enums in sync with what's in gcc and in review D35214 for compiler-rt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307757 91177308-0d34-0410-b5e6-96231b3b80d8
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?
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307520 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@307495 91177308-0d34-0410-b5e6-96231b3b80d8
