The argument to the initialization region of reduction declarations was
never mapped. This meant that if this argument was accessed inside the
initialization region, that mlir operation would be translated to an
llvm operation with a null argument (failing verification).

Adding the mapping ensures that the right LLVM value can be found when
inlining and converting the initialization region.

We have to separately establish and clean up these mappings for each use
of the reduction declaration because repeated usage of the same
declaration will inline it using a different concrete value for the
block argument.

In
     commit 2f63718f
     Author: Jason Molenda <jmolenda@apple.com>
     Date:   Tue Mar 26 09:07:15 2024 -0700

[lldb] Don't clear a Module's UnwindTable when adding a SymbolFile
(#86603)

I stopped clearing a Module's UnwindTable when we add a SymbolFile to
avoid the memory management problems with adding a symbol file
asynchronously while the UnwindTable is being accessed on another
thread. This broke the target-symbols-add-unwind.test shell test on
Linux which removes the DWARF debub_frame section from a binary, loads
it, then loads the unstripped binary with the DWARF debug_frame section
and checks that the UnwindPlans for a function include debug_frame.

I originally decided that I was willing to sacrifice the possiblity of
additional unwind sources from a symbol file because we rely on assembly
emulation so heavily, they're rarely critical. But there are targets
where we we don't have emluation and rely on things like DWARF
debug_frame a lot more, so this probably wasn't a good choice.

This patch adds a new UnwindTable::Update method which looks for any new
sources of unwind information and adds it to the UnwindTable, and calls
that after a new SymbolFile has been added to a Module.

Fixes #86546 and removes the macro `LIBC_HAS_BUILTIN`. This was
necessary to support older compilers that did not support
`__has_builtin`. All of the compilers we support already have this
builtin.
See: https://libc.llvm.org/compiler_support.html
All uses now use `__has_builtin` directly

cc @nickdesaulniers

Revert rG58de1e2c "Fix stack layout for frames larger than 2gb (#84114)"

This is failing on some EXPENSIVE_CHECKS buildbots

The vpr register may no longer be killed where it was, so we should be
removing the kill flags.

We've introduced `__constexpr_memmove` a while ago, which simplified the
implementation of the copy and move lowering a bit. This allows us to
remove some of the boilerplate.

This PR adds handling for TXT records in the GOFF reader.

---------

Authored-by: Yusra Syeda <yusra.syeda@ibm.com>

The SHM or /tmp files that might be created during library registration
don't need to have such open permissions, so this change fixes that.

Flush out the remaining UInt<128> support and add test coverage.

We could have used cpp::popcount in the implementation of
UInt::has_single_bit, but
has_single_bit has a perhaps useful early return.

It is currently not possible to use "RVV type" and "RVV intrinsics" if
the "zve32x" is not enabled globally. However in some cases we may want
to use them only in some functions, for instance:
```
#include <riscv_vector.h>

__attribute__((target("+zve32x")))
vint32m1_t rvv_add(vint32m1_t v1, vint32m1_t v2, size_t vl) {
  return __riscv_vadd(v1, v2, vl);
}

int other_add(int i1, int i2) {
  return i1 + i2;
}
```
, it is supposed to be compilable even the vector is not specified, e.g.
`clang -target riscv64 -march=rv64gc -S test.c`.

For very large stack frames, the offset from the stack pointer to a local can be more than 2^31 which overflows various `int` offsets in the frame lowering code.

This patch updates the frame lowering code to calculate the offsets as 64-bit values and resolves the overflows, resulting in the correct codegen for very large frames.

Fixes #48911

    [RISCV] RISCV vector calling convention (1/2)

    This is the vector calling convention based on
    https://github.com/riscv-non-isa/riscv-elf-psabi-doc,
    the idea is to split between "scalar" callee-saved registers
    and "vector" callee-saved registers. "scalar" ones remain the
    original strategy, however, "vector" ones are handled together
    with RVV objects.

    The stack layout would be:

      |--------------------------| <-- FP
      | callee-allocated save    |
      | area for register varargs|
      |--------------------------|
      | callee-saved registers   | <-- scalar callee-saved
      |        (scalar)          |
      |--------------------------|
      | RVV alignment padding    |
      |--------------------------|
      | callee-saved registers   | <-- vector callee-saved
      |        (vector)          |
      |--------------------------|
      | RVV objects              |
      |--------------------------|
      | padding before RVV       |
      |--------------------------|
      | scalar local variables   |
      |--------------------------| <-- BP
      | variable size objects    |
      |--------------------------| <-- SP

    Note: This patch doesn't contain "tuple" type, e.g. vint32m1x2.
          It will be handled in https://github.com/riscv-non-isa/riscv-elf-psabi-doc (2/2).

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

[X86] combineExtractWithShuffle - use combineExtractFromVectorLoad to extract scalar load from shuffled vector load

Improves #85419

The time spent on parsing `.debug_abbrev` is also part of debug info
parsing time.

I found this issue (a separate one) during the investigation of #86757,
the crash is similar in substituteParameterMappings, but at different
inner places.

This was an out-of-bound issue where we access front element in an empty
written template argument list to get the instantiation source range.
This patch fixes it by adding a proper guard.

If the phi node is trunced, but not its operand(s), need to handle this
situation in the assertion, code already does the right transformation.

The AMDGPUSimplifyLibCalls pass was lowering function calls with the
strictfp attribute to sequences that included function calls incorrectly
lacking the attribute. This patch corrects that.

The pass now also emits the correct constrained fp call instead of
normal FP instructions when in a function with the strictfp attribute.
Replacing non-constrained calls with constrained calls when required
is still on the IRBuilder's TODO list.

This was made unused by d9ec4b24.

On z/OS int128 is disabled causing one of the cases in
`saturate_cast.pass.cpp` to fail. The failure is only in 64-bit mode.
In this case `the std::numeric_limits<long long int>::max()` is within
`std::numeric_limits<unsigned long int>::min()`
and `std::numeric_limits<unsigned long int>::max()` therefore,
saturate_cast<unsigned long int>( sBigMax) == LONG_MAX and not ULONG_MAX
as original test.

In 32-bit, `saturate_cast<unsigned long int>( sBigMax) == ULONG_MAX`
like on other platforms where int128 is enabled.

This PR is required to pass this test case on z/OS and possibly on other
platforms where int128 is not supported/enabled.

---------

Co-authored-by: Sean Perry <perry@ca.ibm.com>

I'm hoping this will fix the errors we've been seeing the last few days:

2024-03-19T20:44:07.4841482Z 2024/03/19 20:44:07 error signing scorecard
json results: error signing payload: getting key from Fulcio: verifying
SCT: updating local metadata and targets: error updating to TUF remote
mirror: invalid key

This upstreams the last bits of Clang API Notes functionality that is
currently implemented in the Apple fork:
https://github.com/apple/llvm-project/tree/next/clang/lib/APINotes

Adjust logic of 1cb9f37a to match freebsd/freebsd-src@9a4d48a645a7a.

D113443 is the original attempt to bring this FreeBSD patch to
llvm-project,
but it never landed. This change is required to build FreeBSD kernel
modules
with -fstack-protector using a standard LLVM toolchain. The FreeBSD
kernel
loader does not handle R_X86_64_REX_GOTPCRELX relocations.

Fixes #50932.

Reland of cfa0833c

Closes #73675

Co-authored-by: Balazs Benics <benicsbalazs@gmail.com>
Co-authored-by: NagyDonat <donat.nagy@ericsson.com>

Prep work for #85419 to make it easier to reuse in other combines

Kernel descriptor attributes, with their respective emit and asm parse functionality, converted to MCExpr.

Relands #80855 with fixes

Currently, the builtins used for implementing `va_list` handling
unconditionally take their arguments as unqualified `ptr`s i.e. pointers
to AS 0. This does not work for targets where the default AS is not 0 or
AS 0 is not a viable AS (for example, a target might choose 0 to
represent the constant address space). This patch changes the builtins'
signature to take generic `anyptr` args, which corrects this issue. It
is noisy due to the number of tests affected. A test for an upstream
target which does not use 0 as its default AS (SPIRV for HIP device
compilations) is added as well.

[llvm-dlltool][llvm-lib][COFF] Don't override NONAME exports with demangled ARM64EC symbols. (#86722)

#78772 added similar support for .def file parser and import library
writer. This PR adds missing bits in LLD to propagate EXPORTAS name and
allow it in `/export` parser. This is syntax is used by MSVC for ARM64EC
`__declspec(dllexport)` handling.

Note we can't use vwaddu.wv because it will get combined away with #78403

Adds logic to the IR verifier that checks whether !tbaa.struct nodes are
well-formed. That is, it checks that the operands of !tbaa.struct nodes
are in groups of three, that each group of three operands consists of
two integers and a valid tbaa node, and that the regions described by
the offset and size operands are non-overlapping.

PR: https://github.com/llvm/llvm-project/pull/86709

add restrict reassoc for the powi(X,Y) / X according the discuss on PR69998.