The return value is not used. This change simplifies an upcoming patch.

We routinely rely on implicit conversions of string literals to
StringRef so that we can use operator==(StringRef, StringRef).

Conversion of floating-point literal to binary representation must be
made using constant rounding mode, which can be changed using pragma
FENV_ROUND. For example, the literal "0.1F" should be representes by
either 0.099999994 or 0.100000001 depending on the rounding direction.

The LHS and RHS are of SmallString and StringRef, respectively.  We
can safely use operator==(StringRef, SringRef) with one implicit
conversion from SmallString to StringRef.

This relocation is used for the 32-bit aligned 21-bit immediate in LDR
Literal instructions.

Fixes test.f90 in #83144.

This issue is observed only when a boolean constant is assigned to a
logical variable. In non-openmp flow, a conversion op is inserted before
assigning it to a logical variable. This patch will insert a fir.convert
operation when the types are not the same, before generating the atomic
write operation.

I've proposed another patch(#85059 ) which removes checks at MLIR level
and looks like it's too permissive. I'm planning to abandon this patch
and address it here.

Note that StringRef::equals has been deprecated in favor of
operator==(StringRef, StringRef).

Align the name to its counterpart `FTInfo` which avoids name aliasing
with llvm::bolt::BranchInfo and allows to drop namespace specifier.

Test Plan: NFC

Reviewers: maksfb, rafaelauler, ayermolo, dcci

Reviewed By: dcci

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

Reverts llvm/llvm-project#92470

Fixes #92350.

Instead, leave the line wrapping as is.

Fixes #43887.
Fixes #44363.

Reviewed By: SixWeining, heiher

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

The 32 bits arguments and returns on LA64 are always sign extended to
i64. So we should be taking this into account around libcalls.

Reviewed By: heiher, SixWeining

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

Reviewed By: SixWeining

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

If an ifunc has local linkage, do not add it into ref edges and mark its
referencer (a function or global variable) not eligible for import. An
ifunc doesn't have summary and ThinLTO cannot promote it. Importing the
referencer may cause linkage errors.

To reference a similar fix, https://reviews.llvm.org/D158961 marks
callers of local ifunc not eligible for import to fix
https://github.com/llvm/llvm-project/issues/58740

The test expectations are otherwise affected by the underlying type of size_t.

[TableGen] Use LessRecord() for the sort in getAllDerivedDefinitions instead of re-implementing it. NFC

Record::getName already returns a StringRef. When this code was
originally written getName returned const std::string &.

In late 2021, both Intel and AMD finally documented that every
AVX-capable CPU has always been guaranteed to execute aligned 16-byte
loads/stores atomically, and further, guaranteed that all future CPUs
with AVX will do so as well.

Therefore, we may use normal SSE 128-bit load/store instructions to
implement atomics, if AVX is enabled.

Per AMD64 Architecture Programmer's manual, 7.3.2 Access Atomicity:

> Processors that report [AVX] extend the atomicity for cacheable,
> naturally-aligned single loads or stores from a quadword to a double
> quadword.

Per Intel's SDM:

> Processors that enumerate support for Intel(R) AVX guarantee that the
> 16-byte memory operations performed by the following instructions will
> always be carried out atomically:
> - MOVAPD, MOVAPS, and MOVDQA.
> - VMOVAPD, VMOVAPS, and VMOVDQA when encoded with VEX.128.
> - VMOVAPD, VMOVAPS, VMOVDQA32, and VMOVDQA64 when encoded with
>   EVEX.128 and k0 (masking disabled).

This was also confirmed to be true for Zhaoxin CPUs with AVX, in
https://gcc.gnu.org/PR104688

Due to how `CodeGenFunction::EmitTrapCheck` is implemented
`SanitizerHandler` with numeric value 0x19 needs to be reserved because
`-fbounds-safety` generates trap instructions with that value embedded
in the trap instructions for x86_64 and arm64 just like for UBSan traps.

** x86_64 **

```
ud1l   0x19(%eax), %eax
```

** arm64 **

```
brk    #0x5519
```

To avoid upstream Clang and AppleClang diverging their ABIs for
`-fbounds-safety` the slot is being reserved in this patch.

`SanitizerHandler::BoundsSafety` currently has no uses in the code but
uses will be introduced when the CodeGen side of `-fbounds-safety`'s
implementation is upstreamed.

rdar://126884014



Co-authored-by: Dan Liew <dan@su-root.co.uk>

this is the dual of ArrayMinCount. I saw that I needed it but it didn't
exist yet

Fixes #91312.

Don't perform the transform if the alias may be replaced at link time.

This solves some ambuguity introduced in P0522 regarding how
template template parameters are partially ordered, and should reduce
the negative impact of enabling `-frelaxed-template-template-args`
by default.

When performing template argument deduction, a template template
parameter
containing no packs should be more specialized than one that does.

Given the following example:
```C++
template<class T2> struct A;
template<template<class ...T3s> class TT1, class T4> struct A<TT1<T4>>; // #1
template<template<class    T5 > class TT2, class T6> struct A<TT2<T6>>; // #2

template<class T1> struct B;
template struct A<B<char>>;
```

Prior to P0522, candidate `#2` would be more specialized.
After P0522, neither is more specialized, so this becomes ambiguous.
With this change, `#2` becomes more specialized again,
maintaining compatibility with pre-P0522 implementations.

The problem is that in P0522, candidates are at least as specialized
when matching packs to fixed-size lists both ways, whereas before,
a fixed-size list is more specialized.

This patch keeps the original behavior when checking template arguments
outside deduction, but restores this aspect of pre-P0522 matching
during deduction.

---

Since this changes provisional implementation of CWG2398 which has
not been released yet, and already contains a changelog entry,
we don't provide a changelog entry here.

This is part of the fixes to address #57353

https://reviews.llvm.org/D133845

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

Currently in Core dumps, the entire pthread is copied, including the
unused space beyond the stack pointer. This causes large amounts of core
dump inflation when the number of threads is high, but the stack usage
is low. Such as when an application is using a thread pool.

This change will optimize for these situations in addition to generally
improving the core dump performance for all of lldb.

Summary:
A runtime library should not have global constructors. Everything is now
expected to go through the init methods. This patch ensures that global
constructors will not accidentally be introduced.

We currently don't support passing files and don't need frontend involvement either.

Split of https://github.com/llvm/llvm-project/pull/90835
Adds support for `TransferReadOfExtractSliceOpFolder` when the
`TransferReadOp` is inside a `MaskOp`.

https://github.com/llvm/llvm-project/pull/71328 refactored
`llvm-profdata.cpp` to use subcommands (which is super nice), but left
many unused `argv` variables. This opts to use `ProgName` where
necessary, and removes `argv` otherwise.

This patch adds comments for writeMemProf{V0,V1,V2} in a
version-specific manner.  The mostly repetitive nature of the comments
is somewhat unfortunate but intentional to make it easy to retire
older versions.

Without this patch, the comment just before writeMemProf documents the
Version1 format, which is very confusing.

Summary:
This was written before we had the address space helpers. Using
numerical address spaces is bad so this should be removed.

Summary:
Previously, the R&R support was global state initialized by a global
constructor. This is bad because it prevents us from adequately
constraining the lifetime of the library. Additionally, we want to
minimize the amount of global state floating around.

This patch moves the R&R support into a plugin member like everything
else. This means there will be multiple copies of the R&R implementation
floating around, but this was already the case given the fact that we
currently handle everything with dynamic libraries.

LLVM is built with C++17, where left shift of any negative value is still UB.
Detected with UBSan on the buildbot.

This reverts commit 0647d103.

Added a unittest demonstrating Error -> Expected<T> forwarding.

The code seems easier to read if it's centered on what the user wants rather than combinations of whatever internal variables.