ResolveCommand will not succeed for an alias command with arguments, and
the code wasn't providing any. Replace that with explicit query(ies) for
the existence of a command with the given name.

This patch adds several const-qualified variants of existing member
functions to `SourceManager`.
I started with removing const qualification from
`setNumCreatedFIDsForFileID`, and removing `const_cast` in the body of
this function, as I think it doesn't make sense to const-qualify
setters.

llvm-project/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp:3084:31:
error: unused variable 'Subtarget' [-Werror,-Wunused-variable]
      const AArch64Subtarget &Subtarget = MF.getSubtarget<AArch64Subtarget>();
                              ^
llvm-project/llvm/lib/Target/AArch64/AArch64FrameLowering.cpp:3253:31:
error: unused variable 'Subtarget' [-Werror,-Wunused-variable]
      const AArch64Subtarget &Subtarget = MF.getSubtarget<AArch64Subtarget>();
                              ^
2 errors generated.

…VE2.1 for spill/fill

When possible the spill/fill register in Frame Lowering uses the ld/st
consecutive pairs available in sme or sve2.1.

This was a side-effect of the "optimization" in #92281. Deoptimize the
code slightly.

This patch fixes:

  mlir/lib/Conversion/ComplexToStandard/ComplexToStandard.cpp:964:26:
  error: missing 'typename' prior to dependent type name Op::Adaptor;
  implicit 'typename' is a C++20 extension
  [-Werror,-Wc++20-extensions]

[SPIR-V] Ensure that internal intrinsic functions for PHI's operand are inserted at the correct positions (#92316)

This PR is to ensure that internal intrinsic functions for PHI's operand
are inserted at the correct positions and don't break rules of
instruction domination and PHI nodes grouping at top of basic block.

The only tricky point here is PlaceSafepoints has an awful hack where
it's creating a legacy PassManager inside it's runImpl, which was not
propagating the incoming TLI. This means there's an implicit bug fix,
where PlaceSafepoints would have been treating too many calls as
builtins.

I'm trying to delete the default constructor altogether, but this seems
to be more difficult.

Specifically, those with small/large absolute values. This ports
https://github.com/openxla/xla/pull/10525 and was verified with XLA's
test suite.

Fixes: #92471

https://github.com/llvm/llvm-project/issues/92309

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

The LHS here are all known to be of StringRef.

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.