Two features (i.e. `frecipe` and `lam-bh`) are added to
`sys.getHostCPUFeatures`. More features will be added in future.
In addition, this patch adds the features returned by
`sys.getHostCPUFeature` when `-march=native`.
Add getHostCPUFeatures into the AArch64 Target Parser to query the
cpuinfo for the device in the case where we are compiling with
-mcpu=native.
Add LLVM_CPUINFO environment variable to test mock /proc/cpuinfo
files for -mcpu=native
Co-authored-by: Elvina Yakubova <eyakubova@nvidia.com>
In https://github.com/llvm/llvm-project/issues/90365 it was reported
that TargetParser arrives at the wrong conclusion regarding what
features are enabled when attempting to detect "native" features on the
Raspberry Pi 4, because it (correctly) detects it as a Cortex-A72, but
LLVM (incorrectly) believes all Cortex-A72s have crypto enabled. Attempt
to help ourselves by allowing runtime information derived from the host
to contradict whatever we believe is "true" about the architecture.
This reverts commit f1905f064451bf688577976a13000c9c47e58452.
This relands commit 19cf8deabe1124831164987f1b9bf2f806c0a875.
There were issues with the preprocessor includes that should have
excluded MSVC still including clang functions building on windows and
using intrin.h. This relanding fixes this behavior by additionally
wrapping the uses of __get_cpuid and __get_cpuid_count in _MSC_VER so
that clang in MSVC mode, which includes intrin.h, does not have any
conflicts.
As discussed at the last sync-up call, mark Zacas as experimental until
this ABI issue is resolved
<https://github.com/riscv-non-isa/riscv-elf-psabi-doc/issues/444>.
Don't return Zacas in getHostCPUFeatures (leaving a TODO there) as even if requesting detection of "native" features, the user likely doesn't want to automatically opt in to experimental codegen.
Previously this took a reference to a map and returned a bool to say
whether it succeeded. We can return a StringMap instead, as all callers
but 1 simply iterated the map if the bool was true, and passed in empty
maps as the starting point.
lldb's lit-cpuid did specifically check whether the call failed, but due
to the way the x86 routines work this works out the same as checking if
the returned map is empty.
This reverts commit f6616e99c71c15d530060346ec29c3246d7fc235.
Was causing buildbot failures on Windows. I also remember seeing a
AMDGPU buildbot failing somewhere on a warning as they have -Werror
enabled.
This reverts commit 2039e130649d8469bc85fa31ba7422d1d3739f90.
This relands commit 19cf8deabe1124831164987f1b9bf2f806c0a875.
Added some additional preprocessor directives to ensure that Host.cpp
only includes cpuid.h when being built on x86.
This patch unifies the implementation of getAMDProcessorTypeAndSubtype
between compiler-rt and LLVM.
This patch is intended to be a step towards pulling these functions out
into identical .inc files to better facilitate code sharing between LLVM
and compiler-rt.
This reverts commit 19cf8deabe1124831164987f1b9bf2f806c0a875.
This was causing quite a few buildbot failures (see the PR description).
Reverting for now while I have time to sort it out. Seems like it should
just be conditional preprocessor macros for X86 however.
This patch makes the host/feature detection in compiler-rt and LLVM use
the functions provided in cpuid.h(__get_cpuid, __get_cpuid_count)
instead of inline assembly. This simplifies the implementation and moves
any inline assembly away to a more common place.
A while ago, some similar cleanup was attempted, but this ended up
resulting in some compilation errors due to toolchain minimum version
issues (https://bugs.llvm.org/show_bug.cgi?id=30384). After the
reversion landed, there have been no attempts since then to clean up the
code, even though the minimum supported compilers now support the
relevant functions (https://godbolt.org/z/o1Mjz8ndv).
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"
