Check that the function has at least one parameter before trying
to access its type.

Fixes https://github.com/llvm/llvm-project/issues/148770.

It should not be possible to construct one without a triple. It would
also be nice to delete TargetLibraryInfoWrapperPass, but that is more
difficult.

While pvalloc() is a legacy POSIX function, it remains widely available
in common C libraries like glibc.

Model pvalloc() in TargetLibraryInfo, allowing LLVM to correctly infer
its attributes.

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'`.

Fixes #138787

To the best of my knowledge, DXIL does not (and should not) support any
of the libcalls in
[`TargetLibraryInfo.def`](https://github.com/llvm/llvm-project/blob/main/llvm/include/llvm/Analysis/TargetLibraryInfo.def).
Math libcalls are not used in HLSL and also do not have lowerings to
DXIL. (The current implementation of math functions are done via
intrinsics.)
If there is a mistake with disabling all libcalls, then the libcalls we
need can be re-enabled in a follow-up PR.

---------

Co-authored-by: Justin Bogner <mail@justinbogner.com>

Renames LIBMVEC-X86 to LIBMVEC and updates TLI to only add the existing
x86 specific mapping when targeting x86.

- Do not call pass initialization from pass constructors.
- Instead, pass initialization should happen in the `initializeAnalysis`
function.
- https://github.com/llvm/llvm-project/issues/111767

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.

The module currently stores the target triple as a string. This means
that any code that wants to actually use the triple first has to
instantiate a Triple, which is somewhat expensive. The change in #121652
caused a moderate compile-time regression due to this. While it would be
easy enough to work around, I think that architecturally, it makes more
sense to store the parsed Triple in the module, so that it can always be
directly queried.

For this change, I've opted not to add any magic conversions between
std::string and Triple for backwards-compatibilty purses, and instead
write out needed Triple()s or str()s explicitly. This is because I think
a decent number of them should be changed to work on Triple as well, to
avoid unnecessary conversions back and forth.

The only interesting part in this patch is that the default triple is
Triple("") instead of Triple() to preserve existing behavior. The former
defaults to using the ELF object format instead of unknown object
format. We should fix that as well.