Update Host.cpp with some missing Arm CPU part identifiers,
to enable `-mcpu=native` on these processors. These are found in
the Technical Reference Manuals listed under "part num" or "part no"
The Ampere1B is Ampere's third-generation core implementing a
superscalar, out-of-order microarchitecture with nested virtualization,
speculative side-channel mitigation and architectural support for
defense against ROP/JOP style software attacks.
Ampere1B is an ARMv8.7+ implementation, adding support for the FEAT
WFxT, FEAT CSSC, FEAT PAN3 and FEAT AFP extensions. It also includes all
features of the second-generation Ampere1A, such as the Memory Tagging
Extension and SM3/SM4 cryptography instructions.
This patch extends the -mcpu/mtune=native support to handle the
Microsoft Azure Cobalt 100 CPU as a Neoverse N2. We expect users to use
-mcpu=neoverse-n2 when targeting this CPU and all the architecture and
codegen decisions to be identical.
The only difference is that the Microsoft Azure Cobalt 100 has a
different Implementer ID in the /proc/cpuinfo entry that needs to be
detected in getHostCPUNameForARM appropriately.
a15532d7647a8a4b7fd2889bd97f6f72f273c4bf landed a patch that added
support for detecting more AMD znver2 CPUs and cleaned up some of the
surrounding code, including the znver3 detection. Since one model group
is 00h-0fh, I adjusted the check to include checking if the value is
greater than zero. Since the value is unsigned, this is always true and
gcc warns on it. This patch removes the comparison with zero to get rid
of the compiler warning.
This patch adds proper detection support for more znver2 CPUs.
Specifically, this adds in support for CPUs codenamed Renoir, Lucienne,
and Mendocino.
This was originally proposedfor Renoir in
https://reviews.llvm.org/D96220 and
got approved, but slipped through the cracks. However, there is still a
demand for this feature.
In addition to adding support for more znver2 CPUs, this patch also includes
some additional refactoring and comments related to cpu model
information for zen CPUs.
Fixes https://github.com/llvm/llvm-project/issues/74934.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Fix the issue that only the server series Tremont processors (Snow Ridge
& Elkhart Lake) can be detected as Tremont, while the client series
(Jasper Lake & Lakefield) will be guessed as Goldmont.
Noted that Lakefield is missing some features compare to other Tremont
processors, but those features are also missing on `FeatureTremont`,
which shouldn't be a problem. Those features are `waitpkg`, `movdiri`
and `movdir64b`.
Don't access leaf 7 subleaf 1 unless subleaf 0 says it is
supported via EAX.
Intel documentation says invalid subleaves return 0. We had been
relying on that behavior instead of checking the max sublef number.
It appears that some Sandy Bridge CPUs return at least the subleaf 0
EDX value for subleaf 1. Best guess is that this is a bug in a
microcode patch since all of the bits we're seeing set in EDX were
introduced after Sandy Bridge was originally released.
This is causing avxvnniint16 to be incorrectly enabled with -march=native
on these CPUs.
Reviewed By: pengfei, anna
Differential Revision: https://reviews.llvm.org/D156963
The bug happens when you build e.g. an x64_64;arm64 JIT with
LLVM_HOST_TRIPLE=x86_64-apple-macos, and then run it on an apple-m1 not under
Rosetta. In that case, sys::getProcessTriple() will return an x86_64 triple,
not an arm64 one.
Differential revision: https://reviews.llvm.org/D138449
The Ampere1A core improves on the Ampere1 with key differences being:
* memory tagging is supported
* SM3/SM4 are supported
* adds a new fusion pair for (A+B+1 and A-B-1)
(added in a later commit)
Depends on D142395
Reviewed By: dmgreen
Differential Revision: https://reviews.llvm.org/D142396
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
component into a new LLVM Component called "TargetParser". This
potentially enables using tablegen to maintain this information, as
is shown in https://reviews.llvm.org/D137517. This cannot currently
be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
information in the TargetParser:
- `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
the current Host machine for info about it, primarily to support
getting the host triple, but also for `-mcpu=native` support in e.g.
Clang. This is fairly tightly intertwined with the information in
`X86TargetParser.h`, so keeping them in the same component makes
sense.
- `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
the target triple parser and representation. This is very intertwined
with the Arm target parser, because the arm architecture version
appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.
And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM
Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.
If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.
Differential Revision: https://reviews.llvm.org/D137838
