Summary:
Use workaround for quadratic behavior inside
AttemptToFoldSymbolOffsetDifference called from BinaryEmitter::emitLSDA.


https://github.com/llvm/llvm-project/commit/b06e736982a3568fe2bcea8688550f9e393b7450#commitcomment-142836456

GNU ld's relocatable linking behaviors:

* Sections with the `SHF_GROUP` flag are handled like sections matched
  by the `--unique=pattern` option. They are processed like orphan
  sections and ignored by input section descriptions.
* Section groups' (usually named `.group`) content is updated as the
  section indexes are updated. Section groups can be discarded with
  `/DISCARD/ : { *(.group) }`.

`-r --force-group-allocation` discards section groups and allows
sections with the `SHF_GROUP` flag to be matched like normal sections.
If two section group members are placed into the same output section,
their relocation sections (if present) are combined as well.
This behavior can be useful when -r output is used as a pseudo shared
object (e.g., FreeBSD's amd64 kernel modules, CHERIoT compartments).

This patch implements --force-group-allocation:

* Input SHT_GROUP sections are discarded.
* Input sections do not get the SHF_GROUP flag, so `addInputSec`
  will combine relocation sections if their relocated section group
  members are combined.

The default behavior is:

* Input SHT_GROUP sections are retained.
* Input SHF_GROUP sections can be matched (unlike GNU ld)
* Input SHF_GROUP sections keep the SHF_GROUP flag, so `addInputSec`
  will create different OutputDesc copies.

GNU ld provides the `FORCE_GROUP_ALLOCATION` command, which is not
implemented.

Pull Request: https://github.com/llvm/llvm-project/pull/94704

To facilitate sharing LoopIdiomTransform between AArch64 and RISC-V,
this first patch moves AArch64LoopIdiomTransform from lib/Target/AArch64
to lib/Transforms/Vectorize and renames it to LoopIdiomVectorize. The
following patch (#94082) will teach LoopIdiomVectorize how to generate VP
intrinsics (in addition to the current masked vector style) in favor of
RVV.

This PR extends Dwarf.def to include the number of operands and the arity (the
number of entries on the DWARF stack).

  - The arity is used in LLDB's DWARF expression evaluator.
  - The number of operands is unused, but is present in the table to avoid
    confusing the arity with the operands. Keeping the latter up to date should
    be straightforward as it maps directly to a table present in the DWARF
    standard.

There were some tests in this file with "noerrno" in the name, but all
the tests were no errno since all the libcalls were declared with
memory(none). Ensure we have adequate coverage for the errno and
no-errno cases by duplicating the libcall transform cases into errno and
non-errno versions with callsite attributes.

Without a value set conditional checks like
if(NOT ${OPENMP_STANDALONE_BUILD})
will not be able to evaluate to true.
Fixes issue introduced from PR #93463, which did not allow the OMPT
variable to be propogated up to offload during a runtimes build.

Two folds unlocked:
    `(icmp eq/ne (xor x, C0), C1)` -> `(icmp eq/ne x, C2)`
    `(icmp eq/ne (xor x, y), 0)` -> `(icmp eq/ne x, y)`

This fixes regressions assosiated with #87180

Closes #87275

Fixes #93104

Prevent a crash by only printing DWARFUnit-unaware information in cases
in which `DWARFUnit* U` is `nullptr`.

When compiling the following code:
```cpp
#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>
#include <stdbool.h>

int main() {
    int a;
    float f;
    scanf("%d", &a);

    scanf("%f", &f);
    a += (int)f;
    
    return a;
}
``` 
for `-march=rv32ima_zbb` we get a libcall:
```
call    scanf
        lw      a0, -20(s0)
        call    __fixsfsi
        mv      a1, a0
```
When we try to use GlobalISel we get this error:
```
 error in backend: unable to legalize instruction: %9:_(s32) = G_FPTOSI %8:_(s32) (in function: main)
```

(Here is a link to a reproducer in Godblot:
https://godbolt.org/z/f67vEEb41 )

The goal of this PR is to do a libcall for the legalization of
`G_FPTOSI` and `G_FPTOUI` instead of doing a fallback to Selection DAG
to do the same libcall later.

[SPIR-V] Improve type inference, addrspacecast and dependencies between SPIR-V entities and required capability/extensions (#94626)

This PR continues https://github.com/llvm/llvm-project/pull/94467 and
contains fixes in emission of type intrinsics, constant recording and
corresponding test cases:
* type-deduce-global-dup.ll -- fix of integer constant emission on
32-bit platforms and correct type deduction for globals
* type-deduce-simple-for.ll -- fix of GEP translation (there was an
issue previously that led to incorrect translation/broken logic of
for-range implementation)

This PR also:
* fixes a cast between identical storage classes and updates the test
case to include validation run by spirv-val,
* ensures that Bitcast for pointers satisfies the requirement that the
address spaces must match and adds the corresponding test case,
* improve encode in Tablegen and decode in code of dependencies between
SPIR-V entities and required capability/extensions,
* prevent emission of identical OpTypePointer instructions.

Needed for getaddrinfo().

Pass the linker LTO options enabled by the clang '-flto' command line
options when targeting bare-metal.

---------

Co-authored-by: Keith Walker <keith.walker@arm.com>

Fixes: 56c4971d

If the default target triple uses visualstudio::Linker::ConstructJob,
when a MSVC installation cannot be found, there will be a
-Wmsvc-not-found diagnostic, which is turned to an error due to -Werror.

We have many driver tests that don't specify --target= and would get a
-Wmsvc-not-found warning, but this might be the only that uses -Werror
and is not skipped by a `UNSUPPORTED`.

It's useful if the probe-based build can consume a dwarf based
profile(e.g. the profile transition), before there is a conflict for the
discriminator, this change tries to mitigate the issue by encoding the
dwarf base discriminator into the probe discriminator.
As the num of probe id(num of basic block and calls) starts from 1,
there are some unused space. We try to reuse some bit of the probe id.
The new encode rule is:
- Use a bit to [28:28] to indicate whether dwarf base discriminator is
encoded.(fortunately we can borrow this bit from the `PseudoProbeType`)
- If the bit is set, use [15:3] for probe id, [18:16] for dwarf base
discriminator. Otherwise, still use [18:3] for probe id.

Note that these doesn't affect the original probe id capacity, we still
prioritize probe id encoding, i.e. the base discriminator is not encoded
when probe id is bigger than [15:3].
 
Then adjust `getBaseDiscriminatorFromDiscriminator` to use the base
discriminator from the probe discriminator.

For baremetal targets that don't support FILE, this version of printf
just writes directly to a function provided by a vendor. To do this both
printf and vprintf were moved to /generic (vprintf since they need the
same flags and cmake gets funky about setting variables in one file and
reading them in another).

For `using std::literals`, we now output:

    error: using declaration cannot refer to a namespace
        4 |   using std::literals;
          |         ~~~~~^
    note: did you mean 'using namespace'?
        4 |   using std::literals;
          |         ^
          |         namespace

Previously, we didn't have the note.

This only fires for qualified namespaces. Just `using std;` doesn't
trigger this, since using declarations without cxx scope specifier are
rejected earlier. Making that work is an exercise for future selves :)

Debug info generation won't emit the alignment of types that have a
standard alignment. It was not taking into account the that case.

rdar://127785973

Only in expensive checks, to match other LazyCallGraph verification.

Is helpful for verifying LazyCallGraph updates. Many issues only surface
when we reuse the LazyCallGraph.

Similar to f7018ba0, this adds patterns for
floating point faddp from an fadd and shuffles.

This reverts commit 35fa2ded.

It broke the LLDB bots on green dragon

Most other instructions accept addresses that start with a '(' without
an immediate before it. The .insn cases were missing. This is also
supported by binutils.

[RISCV] Fold (vXi8 (trunc (vselect (setltu, X, 256), X, (sext (setgt X, 0))))) to vmax+vnclipu. (#94720)

This pattern is an obscured way to express saturating a signed value
into a smaller unsigned value.

If (setltu, X, 256) is true, then the value is already in the desired
range so we can pick X. If it's false, we select (sext (setgt X, 0))
which is 0 for negative values and all ones for positive values. The all
ones value when truncated to the final type will still be all ones like
we want.

Prior to this change, `SelectionDAGBuilder` was producing `SDNode`s of
the form: `f32 = extract_vector_elt <1 x bfloat|half>, i32 0` when
lowering phis of `<1 x bfloat|half>` and running on a target that
promotes this type to `f32` (like some x86 or AMDGPU targets.)

This construct is invalid since this type of node only allows type
extensions for integer types.
It went unotice because the `extract_vector_elt` node is later broken
down in `bitcast` followed by `bf16_to_fp|fp_extend`. However, when the
argument of the phi is a constant we were crashing because the existing
code would try to constant fold this `extract_vector_elt` into a
any_ext.

This patch fixes this by using a proper decomposition for `<1 x
bfloat|half>`:
```
bfloat|half = bitcast <1 x blfoat|half>
float = fp_extend bfloat|half
```

This change should be NFC for the non-constant-folding cases and fix the
SDISel crashes (reported in
https://github.com/llvm/llvm-project/issues/94449) for the folding
cases.

Note: The change on the arm test is a missing fp16 to f32 constant folding
exposed by this patch. I'll push a separate improvement for that.

It also moves the test near other similar test cases.

Otherwise, older copies of LLD may not understand the latest bitcode
versions (for example, if we increase
`ModuleSummaryIndex::BitCodeSummaryVersion`)

Related to
https://github.com/llvm/llvm-project/pull/90692#issuecomment-2113250317

As discussed in #94443, this PR changes the wording to be more correct.

Summary:
AMDGPU supports a `target-id` feature which is used to qualify targets
with different incompatible features. These are both rules and target
features. Currently, we pass `-target-cpu` twice when offloading to
OpenMP, and do not pass the target-id features at all. The effect was
that passing something like `--offload-arch=gfx90a:xnack+` would show up
as `-target-cpu=gfx90a:xnack+ -target-cpu=gfx90a`. Thus ignoring the
xnack completely and passing it twice. This patch fixes that to pass it
once and then separate it like how HIP does.

Add SHAPE runtime API (will be used for assumed-rank, lowering is
generating other cases inline).

I tried to make it in a way were there is no dynamic allocation in the
runtime/deallocation expected to be inserted by inline code for arrays
that we know are small (lowering will just always stack allocate a rank
15 array to avoid dynamic stack allocation or heap allocation).

(and remove an unused argument)

This patch reverts 9b832b72 (#87111):
- [libc++] Deprecated `shared_ptr` Atomic Access APIs as per P0718R2
- [libc++] Implemented P2869R3: Remove Deprecated `shared_ptr` Atomic Access APIs from C++26

As explained in [1], the suggested replacement in P2869R3 is `__cpp_lib_atomic_shared_ptr`,
which libc++ does not yet implement. Let's not deprecate the old way of doing things before
the new way of doing things exists.

[1]: https://github.com/llvm/llvm-project/pull/87111#issuecomment-2112740039

Re-apply https://github.com/llvm/llvm-project/pull/87550 with fixes.

Details:
Some tests in fuchsia failed because of the newly added assertion.
This was because `GetExceptionBreakpoint()` could be called before
`g_dap.debugger` was initted.

The fix here is to just lazily populate the list in
GetExceptionBreakpoint() rather than assuming it's already been initted.
(There is some nuisance here because we can't simply just populate it in
DAP::DAP(), which is a global ctor and is called before
`SBDebugger::Initialize()` is called. )

For regex patterns that produce zero-length matches, there is one
(imaginary) match in-between every character in the sequence being
searched (as well as before the first character and after the last
character). It's easiest to demonstrate using replacement:
`std::regex_replace("abc"s, "!", "")` should produce `!a!b!c!`, where
each exclamation mark makes a zero-length match visible.

Currently our implementation doesn't correctly set the prefix of each
zero-length match, "swallowing" the characters separating the imaginary
matches -- e.g. when going through zero-length matches within `abc`, the
corresponding prefixes should be `{'', 'a', 'b', 'c'}`, but before this
patch they will all be empty (`{'', '', '', ''}`). This happens in the
implementation of `regex_iterator::operator++`. Note that the Standard
spells out quite explicitly that the prefix might need to be adjusted
when dealing with zero-length matches in
[`re.regiter.incr`](http://eel.is/c++draft/re.regiter.incr):
> In all cases in which the call to `regex_search` returns `true`,
`match.prefix().first` shall be equal to the previous value of
`match[0].second`... It is unspecified how the implementation makes
these adjustments.

[Reproduction example](https://godbolt.org/z/8ve6G3dav)
```cpp
#include <iostream>
#include <regex>
#include <string>

int main() {
  std::string str = "abc";
  std::regex empty_matching_pattern("");

  { // The underlying problem is that `regex_iterator::operator++` doesn't update
    // the prefix correctly.
    std::sregex_iterator i(str.begin(), str.end(), empty_matching_pattern), e;
    std::cout << "\"";
    for (; i != e; ++i) {
      const std::ssub_match& prefix = i->prefix();
      std::cout << prefix.str();
    }
    std::cout << "\"\n";
    // Before the patch: ""
    // After the patch: "abc"
  }

  { // `regex_replace` makes the problem very visible.
    std::string replaced = std::regex_replace(str, empty_matching_pattern, "!");
    std::cout << "\"" << replaced << "\"\n";
    // Before the patch: "!!!!"
    // After the patch: "!a!b!c!"
  }
}
```

Fixes #64451

rdar://119912002