When adding information for induction variables, add both unsigned and
signed constraints, with corresponding signed and unsigned
preconditions.

I believe the logic here is equally valid for signed/unsigned, we just
need to add preconditions of the same type.

And add a check in the python script that the binary given to `--qemu`
actually exists. Otherwise you get a generic Python error:
```
 # .---command stderr------------
 # | Traceback (most recent call last):
 # |   File "/home/david.spickett/modules-llvm-project/libcxx/utils/qemu_baremetal.py", line 70, in <module>
 # |     exit(main())
 # |   File "/home/david.spickett/modules-llvm-project/libcxx/utils/qemu_baremetal.py", line 66, in main
 # |     os.execvp(qemu_commandline[0], qemu_commandline)
 # |   File "/usr/lib/python3.8/os.py", line 568, in execvp
 # |     _execvpe(file, args)
 # |   File "/usr/lib/python3.8/os.py", line 610, in _execvpe
 # |     raise last_exc
 # |   File "/usr/lib/python3.8/os.py", line 601, in _execvpe
 # |     exec_func(fullname, *argrest)
 # | FileNotFoundError: [Errno 2] No such file or directory
 # `-----------------------------
 # error: command failed with exit status: 1
```
When it tries to run the entire command later.

For the builder, it's only ever going to use qemu-system-arm so error at
config time if it's not there.

Updated SLEEF and ArmPL tests with Fixed-Width and Scalable cases for
frem. Those are mapped to fmod/fmodf.

Compress promoted instruction (EVEX) to pre-promotion instruction
(legacy/VEX) when R16-R31 is not used.

Alternative of #77065

When demangling a vector variant we are not checking that the number of
parameters is the same as that of the scalar function. This check is
hoisted out of getScalableECFromSignature() making the equvalent check
in the unittests obsolete.

ClangTidy performance suggested to use '\n' instead of std::endl, but it
seems the flushing behavior was intended here (tests started failing).

This re-uses some code extracted earlier from SelectionDAG into
SwitchLoweringUtils

Much of the code is a straight port from SDAG's splitWorkItem(), with
minor changes needed for GISel.

- Use '\n' instead of std::endl;

https://clang.llvm.org/extra/clang-tidy/checks/performance/avoid-endl.html

The attached test case would cause an assertion failure in Pointer.h
when operating on a null pointer.

This revision updates the llvm dialect inliner to explicitly disallow
the inlining of variadic functions. Already previously the inlining
failed if the number of function arguments did not match the number of
call arguments. After the change, inlining checks the function is not
variadic and it does not contain a va_start intrinsic.

This commit adds an optional distinct attribute parameter to the
DISubprogramAttr. This enables modeling of distinct subprograms, as
required for LLVM IR. This change is required to avoid accidential
uniquing of subprograms on functions that would lead to invalid LLVM IR
post export.

properly demonstrates the upcoming change.

This a test for https://github.com/llvm/llvm-project/pull/76774. In the
review comments, we're concerning about the case that ODRHash may
produce the different hash values for semantical same template
arguments. For example, if the template argument in a specialization is
not qualified and the semantical same template argument in the instantiation
point is qualified, we should be able to select that template
specialization. And this patch tests this behavior: we should be able to select
the correct specialization with semantical same template arguments.

This commit adds a distinct attribute parameter to the DICompileUnit to
enable the modeling of distinctness. LLVM requires DICompileUnits to be
distinct and there are cases where one gets two equivalent compilation
units but LLVM still requires differentiates them. We observed such
cases for combinations of LTO and inline functions.

This patch also changes the DIScopeForLLVMFuncOp pass to a module pass,
to ensure that only one distinct DICompileUnit is created, instead of
one for each function.

Also test two issues:

* When the start address is `.`, subsequent sections don't share the
  address of the first overlay section.
* When the first overlay section is empty and discardable, `p_paddr` is
  incorrectly zero. This is because a discarded section has a zero
  address, causing `prev->getLMA() + prev->size` where `prev` refers to
  the first section to evaluate to zero.

Delete the LegalizerInfo comments of AArch64/AMD64/ARM/M68k/RISCV/x86,
they are copied from register bank.

This reverts commit 78550bef since
it broke the two stage build.

To keep the structure of TableGen files clear.

The definitions are simplified by the way.

This contains compiler-rt builtins and llvm-libc for baremetal use.

Differential Revision: https://reviews.llvm.org/D155337

According to https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2844.pdf,
default argument promotions for _FloatN types has been removed.

A warning is needed to notice user to promote _Float16 to double
explicitly, and then pass it to format specifier '%f', which is
consistent with GCC.

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

fixes https://github.com/llvm/llvm-project/issues/47156 
fixes https://github.com/llvm/llvm-project/issues/47155

Whether runtime registration is needed is not dependent on the OS but
the file format. For ELF, COFF, Mach-O or XCOFF, we can always use the
linker support. This is important for baremetal platforms such as RTOS
and UEFI platforms where there is no OS but we still don't want to use
runtime registration and rely on linker support instead.

I plan to define RISCV::relocateAllocate in a subsequent change.
Add a test to verify
`else if (auto *ehIn = dyn_cast<EhInputSection>(&sec)) secAddr += ehIn->getParent()->outSecOff;`

Windows barfs on the 'friend class SizeOffsetType;' statement. Attempt
to fix by making the method called by the "friend" class public.

[clang] [MinGW] Don't look for a GCC in path if the install base has a proper mingw sysroot (#76949)

This fixes uses of the MSYS2 clang64 environment compilers, if another
set of GCC based compilers are available further back in PATH (which may
be explicitly added, or inherited unintentionally from other software
installed).

(The issue in the clang64 environment can be worked around somewhat by
installing *-gcc-compat packages which present aliases named
<triple>-gcc within the clang64 environment as well.)

This fixes https://github.com/msys2/MINGW-packages/issues/11495 and
https://github.com/msys2/MINGW-packages/issues/19279.

Since #72467, `@plt` in assembly output "call foo@plt" is omitted. We
can trivially merge MO_PLT and MO_CALL without any functional change to
assembly/relocatable file output.

Earlier architectures use different call relocation types whether a PLT
is potentially needed: R_386_PLT32/R_386_PC32, R_68K_PLT32/R_68K_PC32,
R_SPARC_WDISP30/R_SPARC_WPLT320. However, as the PLT property is
per-symbol instead of per-call-site and linkers can optimize out a PLT,
the distinction has been confusing.

Arm made good names R_ARM_CALL/R_AARCH64_CALL. Let's use MO_CALL instead
of MO_PLT.

As follow-ups, we can merge fixup_riscv_call/fixup_riscv_call_plt and
VK_RISCV_CALL/VK_RISCV_CALL_PLT.

R_RISCV_CALL/R_RISCV_CALL_PLT distinction is not necessary and
R_RISCV_CALL has been deprecated. Since https://reviews.llvm.org/D132530
`call foo` assembles to R_RISCV_CALL_PLT. The `@plt` suffix is not
useful and can be removed now (matching AArch64 and PowerPC).

GNU assembler assembles `call foo` to RISCV_CALL_PLT since 2022-09
(70f35d72ef04cd23771875c1661c9975044a749c).

Without this patch, unconditionally changing MO_CALL to MO_PLT could
create `jump .L1@plt, a0`, which is invalid in LLVM integrated assembler
and GNU assembler.

Close #77201. When linking code with a R_X86_64_TPOFF64 relocation, LLD
exits with an 'unknown reloaction' error message due to two missing
cases in relocation switch statements. This patch adds in those cases so
that LLD successfully links code R_X86_64_TPOFF64 relocations.

Summary:
A previous patch added a dependency on the stack protectors, this was
not built on the GPU targets so every test was disabled. It turns out
that disabled tests still get targets so we need to specifically check
if the it is in the target's set of entrypoints before we can use it.

Another patch, because the build-bot was down, snuck in that prevented
the new math tests from being run. The problem is that the `signal.h`
header requires target specific definitions but was being used
unconditionally. I have made changes that disable building this header
if the file is not defined in the config. This required disbaling the
signal_to_string utility, so that will simply be missing from targets
that don't define it.

Fixes build on Windows in C++26 mode.

Reverted in:
https://github.com/llvm/llvm-project/commit/40c07b559aa6ab4bac074c943967d3207bc07ae0
Original PR: https://github.com/llvm/llvm-project/pull/76632



---------

Co-authored-by: Zingam <zingam@outlook.com>

This will help re-use this code with the upcoming GlobalISel implementation of
this optimization.

Tiny spelling mistake fixup. please review the two lines of code below
to see the correctness of this PR.