Replaces all the uses of `+zcm` with `+zcm-gpr64`. A fix for: https://github.com/llvm/llvm-project/pull/146051
This patch adds support for the `libmvec` vector library on AArch64 targets. Currently, all `libmvec` functions in GLIBC version 2.40 are supported. The full list of math functions enabled can be found [here](https://github.com/bminor/glibc/blob/96abd59bf2a11ddd4e7ccaac840ec13c0b62d3ba/sysdeps/aarch64/fpu/Versions) (up to GLIBC 2.40). Previously, `libmvec` was only supported on x86_64 targets. Attempts to use it on AArch64 resulted in the following error from Clang: `unsupported option 'libmvec' for target 'aarch64'`.
Renames LIBMVEC-X86 to LIBMVEC and updates TLI to only add the existing x86 specific mapping when targeting x86.
In current `FlattenCFG`, using `isNoAlias` for two instructions is imprecise. For example, when passing a store instruction and a load instruction directly into `AA->isNoAlias`, it will always return `NoAlias`. This happens because when checking the types of the two Values, the store instruction (which has a `void` type) causes the analysis to return `NoAlias`. For instructions, we should use `getModRefInfo` instead of `isNoAlias`, as aliasing is a concept of memory locations. In this patch, `AAResults::getModRefInfo` is supported to take in two instructions. It will check whether two instructions may access the same memory location or not. And in `FlattenCFG`, we use this new helper function to do the check instead of `isNoAlias`. Unit tests and lit tests are also included to this patch.
Some ArmPL vector math routines that operate on fixed-width vector types obey the aarch64_vector_pcs calling convention, e.g. armpl_vsinq_f64, etc. This patch adds support for functions in the TLI to specify an optional calling convention to be added to the declared function. Once this patch lands I intend to follow up with a vectoriser patch that adds this optional calling convention when invoking the vector library variant from the loop vectoriser.
These date back to when the non-intrinsic format of variable locations was still being tested and was behind a compile-time flag, so not all builds / bots would correctly run them. The solution at the time, to get at least some test coverage, was to have tests opt-in to non-intrinsic debug-info if it was built into LLVM. Nowadays, non-intrinsic format is the default and has been on for more than a year, there's no need for this flag to exist. (I've downgraded the flag from "try" to explicitly requesting non-intrinsic format in some places, so that we can deal with tests that are explicitly about non-intrinsic format in their own commit).
This is an upstream proposal from https://github.com/intel/intel-graphics-compiler/commit/e60884cb98c4332a0eecff8396eb353c5b86cd35 We observed malfunctioning StripNonLineTableDebugInfo during debugging and it's caused by out-of-order evaluation, this is a C++ level semantic ambiguity issue, refer https://en.cppreference.com/w/cpp/language/eval_order Solution is simply separating one line into two.
SLEEF math vector library now supports RISC-V target. Commit: https://github.com/shibatch/sleef/pull/477 This patch enables the use of auto-vectorization with subsequent replacement by the corresponding SLEEF function.