Fix buildbot failure after D112940

Change a type from `int64_t` to `long long` to make a buildbot happy.

https://lab.llvm.org/buildbot/#/builders/196/builds/7371

```
error: no matching function for call to 'getAsSignedInteger'
 if (getAsSignedInteger(ValStr, 0, Val))
```

Worked With My Compiler (TM)

RegScavenger: Add function to externally reserve a scavenging index

AMDGPU separately tracks the frame index we use for the emergency
spill slot. In the case where we need to spill SGPRs to memory, we
manually handle the save and restore. In other cases, the scavenger
handles the spills normally.

In a future change, I will need to add a second scavenging index in
order to free a second register in case we are spilling to a large
offset and also have to avoid clobbering a condition register
(SCC). In the intersection of these two cases, we will end up
recursively calling eliminateFrameIndex. We need to report to the
scavenger that the first scavenging frame index is unavailable, and
that the register is already used to avoid double spilling to the
scavenging slot (and avoid clobbering the previously evicted register,
and getting the same register for both scavenge calls).

This is really ugly but I don't see a better way without requiring
targets to be far more aware of how the scavenger iterator is
advanced.

[mte] fix compiler crash with musttail.

see D118852 for matching hwasan fix.

Reviewed By: eugenis

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

Add a tool for diffing size remarks

This is a tool which can handle bitstream and YAML remarks. The idea here is to
provide more insight into which functions changed in a benchmark when testing
compiler changes.

E.g. "foo got 20% bigger, so maybe we should look more closely at that."

To use the tool, you can use...

```
$ llvm-remark-size-diff remarks_file_a remarks_file_b --parser=yaml|bitstream
```

... on two remarks files containing at least instruction count remarks. This
will output some data on instruction count change and also other relevant
information such as stack size change from `remarks_file_a` to `remarks_file_b`.

This is a bit of a WIP so I'm happy to change the format etc. Ultimately I think
it'd be best to have some JSON output which could be consumed by another tool.
But some base-level, greppable output is very handy to have anyway.

The format I'm proposing here is

```
<files> <inc/dec in inst count> <fn name> <inst count change> <stack B change>
```

Where the files and increase/decrease are indicated like below:

- `<files>` is one of `++` (file B), `--` (file A), `==` (both)
- `<inc/dec in inst count>` is one of `>` (increase) or `<` (decrease)

This makes it easy to grep for things like "which functions appeared in A but
did not appear in B?" Or "what are all the instruction count decreases?"

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

[NFC] pull retvec logic to MemoryTaggingSupport.

we will also need this for aarch64 stack tagging.

Reviewed By: eugenis

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

AMDGPU: Add second emergency slot for SGPR to vmem for large frames

In a future change, we will sometimes use a VGPR offset for doing
spills to memory, in which case we need 2 free VGPRs to do the SGPR
spill. In most cases we could spill the VGPR along with the SGPR being
spilled, but we don't have any free lanes for SGPR_1024 in wave32 so
we could still potentially need a second scavenging slot.

[SimplifyCFG] Fix -Wunused-variable in -DLLVM_ENABLE_ASSERTIONS=off builds

[mlir] Remove dangling reference to std-bufferize which got removed

[flang] Add a semantics test for co_broadcast

Test a range of acceptable forms of co_broadcast calls, including
combinations of keyword and non-keyword actual arguments of
intrinsic and derived type.  Also test that several invalid forms
of co_sum call generate the correct error messages.

Reviewed By: ktras

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

[lld-macho] Fix duplicate symbols with relocatable objects

In the case your framework bundles contain relocatable objects, and your
objects include LC_LINKER_OPTIONs for the framework, previously they
would not be deduplicated like they would have if they were static
archives. This was also the case if you passed `-framework` for the
framework as well.

Reviewed By: #lld-macho, thakis, oontvoo

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

Skip exception cleanups when the innermost scope is EHTerminateScope.

EHTerminateScope is used to implement C++ noexcept semantics. Per C++
[except.terminate], it is implemented-defined whether no, some, or all
cleanups are run prior to terminatation.

Therefore, the code to run cleanups on the way towards termination is
unnecessary, and may be omitted.

After this change, we will still run some cleanups: any cleanups in a
function called from the noexcept function will continue to run, while
those in the noexcept function itself will not.

(Commit attempt 2: check InnermostEHScope != stable_end() before accessing it.)

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

[mlir:Standard] Remove support for creating a `unit` ConstantOp

This is completely unused upstream, and does not really have well defined semantics
on what this is supposed to do/how this fits into the ecosystem. Given that, as part of
splitting up the standard dialect it's best to just remove this behavior, instead of try
to awkwardly fit it somewhere upstream. Downstream users are encouraged to
define their own operations that clearly can define the semantics of this.

This also uncovered several lingering uses of ConstantOp that weren't
updated to use arith::ConstantOp, and worked during conversions because
the constant was removed/converted into something else before
verification.

See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for more discussion.

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

[mlir] Move StandardOps/Utils to Arithmetic and sever a bunch of dependencies on Standard

The Utils.cpp file in StandardOps essentially just contains utilities for interacting with arithmetic
operations, and at this point makes more sense as a utility file for the arithemtic dialect.

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

[mlir] Move SelectOp from Standard to Arithmetic

This is part of splitting up the standard dialect. See https://llvm.discourse.group/t/standard-dialect-the-final-chapter/ for discussion.

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

[mlir] Split std.splat into tensor.splat and vector.splat

This is part of the larger effort to split the standard dialect. This will also allow for pruning some
additional dependencies on Standard (done in a followup).

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

[mte] support more complicated lifetimes (e.g. for exceptions).

Reviewed By: eugenis

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

[InstrProf][NFC] Remove stray option in InstrProfWriter

This variable was added to `InstrProfWriter.cpp`  in D115693 by mistake and it isn't needed.

Reviewed By: kyulee

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

AMDGPU [NFC]: Fix a few typos in docs AMDGPUUsage.rst

Summery:
  Fix a few typos in docs AMDGPUUsage.rst

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

[LLDB] add sub regigter enums on x64 Windows

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

[release] Use the Bootstrapping build for building LLVM releases

Instead of using the (now deprecated) Projects build for libcxx, libcxxabi,
libunwind and compiler-rt, this patch uses the Bootstrapping build. This
implies that Clang will be built from scratch, and then the runtimes will
be built using that just-built Clang instead of the system compiler.
This is the correct way of assembling a toolchain, since we don't want
to ship runtimes that were built with a non-Clang compiler (or a
potentially older Clang).

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

[lld-macho][nfc] Hoist out creation of Section in parseSections()

Simplifies the code slightly.

Reviewed By: #lld-macho, thakis

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

[x86] add test for 'sbb' false dependency stall; NFC

[x86] make helper function to create sbb with zero operands; NFC

As noted in D116804, we want to effectively invert that patch
for CPUs (intel) that don't break the false dependency on
sbb %eax, %eax

So we will likely want to create that here in the
X86DAGToDAGISel::Select() case for X86::SETCC_CARRY.

[mte] work around lifetime issue with setjmp.

setjmp can return twice, but PostDominatorTree is unaware of this. as
such, it overestimates postdominance, leaving some cases where memory
does not get untagged on return. this causes false positives later in
the program execution.

this is a workaround for now, in the longer term PostDominatorTree
should be made aware of returns_twice, as this may cause problems
elsewhere.

See D118647 for equivalent fix to HWASan.

Reviewed By: eugenis

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

[flang] Modify right modes for READ/WRITE vs OPEN

When a mode flag is modified (e.g., BLANK='ZERO') in an I/O data transfer
statement, ensure that the right set of mode flags is modified.
There's one set of mode flags that are captured by an OPEN
statement and maintained in the connection, and another that
is maintained in an I/O statement state record for local mutability.
Some I/O API routines were unconditionally modifying the persistent
set of flags.

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

[NFC] remove excessive whitespace.

[mlir][NFC] Update remaining dialect operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update PDL operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update GPU/SCF operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update Affine operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update OpenACC/OpenMP operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update MemRef/Tensor operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update Vector operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update AMX/LLVM/NVVM/X86 vector operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update SPIRV operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir][NFC] Update Toy operations to use `hasVerifier` instead of `verifier`

The verifier field is deprecated, and slated for removal.

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

[mlir] Refactor how additional verification is specified in ODS

Currently if an operation requires additional verification, it specifies an inline
code block (`let verifier = "blah"`). This is quite problematic for various reasons, e.g.
it requires defining C++ inside of Tablegen which is discouraged when possible, but mainly because
nearly all usages simply forward to a static function `static LogicalResult verify(SomeOp op)`.
This commit adds support for a `hasVerifier` bit field that specifies if an additional verifier
is needed, and when set to `1` declares a `LogicalResult verify()` method for operations to
override. For migration purposes, the existing behavior is untouched. Upstream usages will
be replaced in a followup to keep this patch focused on the hasVerifier implementation.

One main user facing change is that what was one `MyOp::verify` is now `MyOp::verifyInvariants`.
This better matches the name this method is called everywhere else, and also frees up `verify` for
the user defined additional verification. The `verify` function when generated now (for additional
verification) is private to the operation class, which should also help avoid accidental usages after
this switch.

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

[libc++][ranges][NFC] Small updates to the Ranges status page:

- note that `split_view` has been renamed to `lazy_split_view`.
- fix formatting.

[gn build] Port 712b31e2d4dc

[libc++][ranges] Implement `indirectly_copyable{,_storable}`.

Also refactor tests for `indirectly_movable{,_storable}`.

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

[NFC] factor isStandardLifetime out of HWASan

this is so we can use it for aarch64 stack tagging.

Reviewed By: eugenis

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

[libc++][ranges][NFC] In the Ranges status, mark move_sentinel as "in progress"

The methods visited for a special class must have an identifier.

[flang] Debugging of ACCESS='STREAM' I/O

Corrects the runtime implementation of I/O on files with
the access mode ACCESS='STREAM'.  This is a collection
of edge-case tweaks to ensure that the distinctions between
stream and direct/sequential files, unformatted or formatted,
are respected where appropriate.
Moves NextInField() from io-stmt.h to io-stmt.cpp --
it was getting too big to keep in a header.

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

Follow up to 6e03a68b776dc, squelch another leak

This patch is a sticking-paster until D118774 solves the situation with
unique_ptrs. I'm certainly wishing I'd focused on that first X_X.

[libc++][ranges][NFC] Test new requirements for `basic_string_view` and `span` iterators.

Note that most changes to `strings` and `views.span` from the One Ranges
Proposal are no longer applicable:
- free `begin` and `end` functions taking `basic_string_view` and `span`
  were removed by [P1870](http://wg21.link/p1870);
- `span::const_iterator` was removed by [LWG3320](https://cplusplus.github.io/LWG/lwg-defects.html#3320).

Reviewed By: #libc, Quuxplusone, ldionne

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

[libc++][ranges][NFC] Add contiguous_iterator_tag to the <iterator> synopsis

It was previously implemented by commit [45d048c20](https://reviews.llvm.org/rG45d048c20440989df2b4e1be1f9343225e7741ab).

Reviewed By: #libc, Quuxplusone, philnik, ldionne

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

[OMPIRBuilder] Add support for atomic compare

This patch adds the support for `atomic compare` in `OMPIRBuilder`.

Reviewed By: jdoerfert

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

[libc++] Add UNSUPPORTED for clang-15

This started breaking in the CI because we bumped the Clang version
to 15, which requires adjusting the markup in the test suite.

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

[RISCV] Cleanup some places that assumed VLMaxSentinel and -1 constant mean the same thing. NFCI

VLMaxSentintel happens to be represented as -1 TargetConstant. A user
provided -1 would be an ISD::Constant. We shouldn't assume that they
are the same thing. I'm still not entirely convinced that we should be
treating -1 from the user as VLMAX.

Also fix one place that failed to use XLenVT for the VLMaxSentinel,
using MVT::i64 in code that only executes on RV32.

[libc][bazel overlay] Add a target for strncpy.

Revert "[SLP]Alternate vectorization for cmp instructions."

This reverts commit 842a2360a84692f2e4c37cc3e652640e6627d004 to fix the
bugs reported by users in https://reviews.llvm.org/D115955#3291538.

[LoopFuse] Change DT to reference in FusionCandidate struct. NFC

Assertion added in f50821cff0 confirms that the DT is indeed nonnull.
Change it to a reference instead of a pointer to make this explicit in
FusionCandidate.
Suggested in D118472.

[analyzer] Add support for __attribute__((returns_nonnull)).

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

[DebugInfo] Re-enable instruction referencing for x86_64

After discussion in D116821 this was turned off in 74db5c8c95e,
14aaaa12366f7 applied to limit the maximum memory consumption in rare
conditions, plus some performance patches.

[IRSim] Make sure that commutative intrinsics are treated as function calls without commutativity

Created to fix: https://github.com/llvm/llvm-project/issues/53537

Some intrinsics functions are considered commutative since they are performing operations like addition or multiplication. Some of these have extra parameters to provide extra information that are not part of the operation itself and are not commutative. This makes sure that if an instruction that is an intrinsic takes the non commutative path to handle this case.

Reviewer: paquette

Closes Issue #53537

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

CodeGen: Use asm register names in warning message

This was using the ugly tablegenerated register enum names, which are
really hideous for register tuples on AMDGPU. Use the prettier names
which are recognized by the asm parser.

AMDGPU: Implement isAsmClobberable

Warn on inline assembly clobbering reserved registers. It should also
warn on at least some reserved register defs, but that isn't happening
right now. If you have a def and re-use of a register we reserve, the
register coalescer will eliminate the intermediate virtual
register. When the reserved reg def is introduced later by the
backend, it will end up clobbering the value the register coalescer
assumed was live through the range.

There is also isInlineAsmReadOnlyReg, although I don't understand what
the distinction really is. It's called in SelectionDAGBuilder, long
before the set of reserved registers is frozen so I'm not sure how
that can possibly work reliably.

Unfortunately this is also using the ugly tablegenerated names for the
registers.

[clang] fix out of bounds access in an empty string when lexing a _Pragma with missing string token

The lexer can attempt to lex a _Pragma and crash with an out of bounds string access when it's
lexing a _Pragma whose string token is an invalid buffer, e.g. when a module header file from which the macro
expansion for that token was deleted from the file system.

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

[flang] Silence bogus error on use after IMPORT

When a scope uses an explicit IMPORT statement to import a
symbol from the scope's host, it should not emit a bogus error
message later if that symbol is used in a specification construct.
The code that checks for imports being hidden by local declarations
was not allowing for the presence of host association (or USE)
indirection symbols in the local scope.  Fix by using GetUltimate()
before checking for the hidden symbol.

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

[flang] prevent rewrite of CMPLX with dynamically optional Y argument

CMPLX was always rewritten as a complex constructor, but the second operand
of a complex constructor cannot be dynamically absent (i.e., a
disassociated pointer, an unallocated allocatable or an absent OPTIONAL
dummy argument), while the second argument of CMPLX can be dynamically
absent.

To avoid having to generate branches in complex constructor lowering
when Y is a pointer, keep the distinction between CMPLX and a complex
constructor when Y is a pointer, an allocatable, or an OPTIONAL entity.

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

[flang] Fix: use right symbol for parent component

When constructing the representation for a component reference
to an inherited component, expression semantics make the parent
component references explicit in the DataRef; e.g., base%component
becomes base%parent%grandparent%component if component was
inheritance-associated through two levels.  But expression semantics
was inserting references to the symbol table entries for the
intermediate types, not the symbols for the parent components in
the extended types.  (We didn't notice the distinction until
recently because both symbols have the same name; this only
affects lowering.)  Find and use the right symbols.

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

[libc++] [NFC] s/__referenceable/__can_reference/

The Standard name for this exposition-only concept is _can-reference_.

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

[SLP]Alternate vectorization for cmp instructions.

Added support for alternate ops vectorization of the cmp instructions.
It allows to vectorize either cmp instructions with same/swapped
predicate but different (swapped) operands kinds or cmp instructions
with different predicates and compatible operands kinds.

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

[lldb] [Commands] Implement "thread siginfo"

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

[PowerPC] Fixing buildbod failure ppc64le-lld-multistage-test

[mlir] Support verification order (1/3)

This CL supports adding dependency between traits verifiers and the
dependency will be checked statically.

Reviewed By: jpienaar

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

[clang][Sparc] Fix __builtin_extract_return_addr etc.

While investigating the failures of `symbolize_pc.cpp` and
`symbolize_pc_inline.cpp` on SPARC (both Solaris and Linux), I noticed that
`__builtin_extract_return_addr` is a no-op in `clang` on all targets, while
`gcc` has non-default implementations for arm, mips, s390, and sparc.

This patch provides the SPARC implementation.  For background see
`SparcISelLowering.cpp` (`SparcTargetLowering::LowerReturn_32`), the SPARC
psABI p.3-12, `%i7` and p.3-16/17, and SCD 2.4.1, p.3P-10, `%i7` and
p.3P-15.

Tested (after enabling the `sanitizer_common` tests on SPARC) on
`sparcv9-sun-solaris2.11`.

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

[RISCV] Add DAG combines to transform ADD_VL/SUB_VL into widening add/sub.

This adds or reuses ISD opcodes for vadd.wv, vaddu.wv, vadd.vv, vaddu.vv
and a similar set for sub.

I've included support for narrowing scalar splats that have known
sign/zero bits similar to what was done for MUL_VL.

The conversion to vwadd.vv proceeds in two phases. First we'll form
a vwadd.wv by narrowing one of the operands. Then we'll visit the
vwadd.wv to try to narrow the other operand. This turned out to be
simpler than catching all the cases in one step. The forming of of
vwadd.wv can happen for either operand for add, but only the right
hand side for sub since sub isn't commutable.

An interesting quirk is that ADD_VL and VZEXT_VL/VSEXT_VL are formed
during vector op legalization, but VMV_V_X_VL isn't usually formed
until op legalization when BUILD_VECTORS are handled. This leads to
VWADD_W_VL forming in one DAG combine round, and then a later DAG combine
round sees the VMV_V_X_VL and needs to commute the operands to get the
splat in position. This alone necessitated a VWADD_W_VL combine function
which made forming vwadd.vv in two stages an easy choice.

I've left out trying hard to form vwadd.wx instructions for now. It would
only save an extend in the scalar domain which isn't as interesting.

Might need to review the test coverage a bit. Most of the vwadd.wv
instructions are coming from vXi64 tests on rv64. The tests were
copy pasted from the existing multiply tests.

Reviewed By: rogfer01

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

[NFC] TypePromotion tests

[flang] Switch return to ExtendedValue in AbstractConverter and Bridge

Change the signature of `genExprAddr`, `genExprValue` to return a `fir::ExtendedValue` instead of a simple `mlir::Value`

This patch is a preparation for more lowering to be upstream. It supports D118786 and D118787.

This patch is part of the upstreaming effort from fir-dev branch.

Reviewed By: kiranchandramohan

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

[libc++] UNSUPPORT GDB pretty printers with Clang 15 (which is what main is)

[flang] Set right "inNamelist" flag

NAMELIST I/O was inconsistent in its choice of which set of I/O modes
to set the "inNamelist" flag.  The wrong choice was in the set of modes
that are part of the persistent state of an I/O connection; the right
place is the set of modes that are reinitialized at the beginning of
each I/O statement so that they can be modified by READ/WRITE control
list specifiers and FORMAT control edit descriptors.  Fix.

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

[AMDGPU] Use new target MMO flag MONoClobber

This allows us to set the noclobber flag on (the MMO of) a load
instruction instead of on the pointer. This fixes a bug where noclobber
was being applied to all loads from the same pointer, even if some of
them were clobbered.

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

[libc++] [test] Fix a couple of copy-paste comments. NFC.

Add missing include diagnosed by the modules build.

Remove redundant LLVM_HAS_RVALUE_REFERENCE_THIS and LLVM_LVALUE_FUNCTION defines

Now that VS2017 support has been dropped (D114639), the LLVM_HAS_RVALUE_REFERENCE_THIS define is always true and the LLVM_LVALUE_FUNCTION define is always enabled for ref-qualifiers.

This patch proposes we remove the defines and use the qualifiers directly.

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

[Function Specialisation] Fix use after free

This is a fix for a use-after-free found by the address sanitizer when
compiling GCC: https://github.com/llvm/llvm-project/issues/52821

The Function Specialization pass may remove instructions, cached
inside the PredicateBase class, which are later being dereferenced
from the SCCPInstVisitor class. To prevent the dangling references
I am lazily deleting the dead instructions after the Solver has run.

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

[clang][macho] add clang frontend support for emitting macho files with two build version load commands

This patch extends clang frontend to add metadata that can be used to emit macho files with two build version load commands.
It utilizes "darwin.target_variant.triple" and "darwin.target_variant.SDK Version" metadata names for that.

MachO uses two build version load commands to represent an object file / binary that is targeting both the macOS target,
and the Mac Catalyst target. At runtime, a dynamic library that supports both targets can be loaded from either a native
macOS or a Mac Catalyst app on a macOS system. We want to add support to this to upstream to LLVM to be able to build
compiler-rt for both targets, to finish the complete support for the Mac Catalyst platform, which is right now targetable
by upstream clang, but the compiler-rt bits aren't supported because of the lack of this multiple build version support.

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

TrigramIndex.h - move unnecessary StringRef include down to TrigramIndex.cpp

[libc++] Guard bits of 598983d7 against _LIBCPP_HAS_NO_CONCEPTS.

[gn build] Port 256d2533322c

[IRBuilder] Reformat two functions (NFC)

These were using 1-space indentation.

[libc++] [NFC] Normalize some `#ifndef _LIBCPP_HAS_NO_CONCEPTS`.

[libc++] [NFC] s/_LIBCPP_STD_VER > 17 && !defined(_LIBCPP_HAS_NO_CONCEPTS)/!defined(_LIBCPP_HAS_NO_CONCEPTS)/

Per Discord discussion, we're normalizing on a simple `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
so that we can do a big search-and-replace for `!defined(_LIBCPP_HAS_NO_CONCEPTS)`
back into `_LIBCPP_STD_VER > 17` when we're ready to abandon support for concept-syntax-less
compilers.

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

Follow up to 9fd9d56dc6b, avoid a memory leak

Gaps in the basic block number range (from blocks being deleted or folded)
get block-value-tables allocated but never ejected, leading to a memory
leak, currently tripping up the asan buildbots. Fix this up by manually
freeing that memory.

As suggested elsewhere, if these things were owned by a unique_ptr then
cleanup would happen automagically. D118774 should eliminate the need for
this dance.

[ConstraintElimination] Add tests with signed predicates and GEPs.

[PowerPC] Scalar IBM MASS library conversion pass

This patch introduces the conversions from math function calls
to MASS library calls. To resolves calls generated with these conversions, one
need to link libxlopt.a library. This patch is tested on PowerPC Linux and AIX.

Differential: https://reviews.llvm.org/D101759

Reviewer: bmahjour

[libc++] Add CI without experimental features and don't exclude span from the tests

There is no reason for the parts of std::span that don't depend on ranges
to be disabled when ranges aren't provided. Also, to make sure the
"no-experimental-stuff" configuration is tested, add a CI job for it.

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

[llvm-rc] Use cast<> instead of dyn_cast<> to avoid dereference of nullptr

The pointer is dereferenced immediately, so assert the cast is correct instead of returning nullptr

Signposts.h - move unnecessary StringRef include down to Signposts.cpp

Fix buildbreak introduced in ed2deab5956fea9e8f64ef6020fe0b4e19734ecc

[nfc][regalloc] Make the max inference cutoff configurable

Added a flag to make configurable the number of interferences after
which we 'bail out' and treat a set of intervals as un-evictable. Also
using it on the ML side, as it turns out to be a good control for
compile-time.

With this configurable, we can do a bit of trial and error and see if
bumping it has any effect on heuristic/policy quality.

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

Also document -arch as -arch is mac specific

Reviewed By: serge-sans-paille

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

[DebugInfo][InstrRef] Fix a tombstone-in-DenseMap crash from D117877

This is a follow-up to D117877: variable assignments of DBG_VALUE $noreg,
or DBG_INSTR_REFs where no value can be found, are represented by a
DbgValue object with Kind "Undef", explicitly meaning "there is no value".
In D117877 I added a special-case to some assignment accounting faster,
without considering this scenario. It causes variables to be given the
value ValueIDNum::EmptyValue, which then ends up being a DenseMap key. The
DenseMap asserts, because EmptyValue is the tombstone key.

Fix this by handling the assign-undef scenario in the special case, to
match what happens in the general case: the variable has no value if it's
only ever assigned $noreg / undef.

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

[NFC][SimplifyCFG] Merge `FoldTwoEntryPHINode()` into it's only callee

[NFC][SimplifyCFG] `FoldTwoEntryPHINode()`: s/BB/MergeBB/

[SimplifyCFG] Start redesigning `FoldTwoEntryPHINode()`.

The current `FoldTwoEntryPHINode()` is not quite designed correctly.
It starts from the merge point, and then tries to detect
the 'divergence' point.

Because of that, it is limited to the simple two-predecessor case,
where the PHI completely goes away. but that is rather pessimistic,
and it doesn't make much sense from the costmodel side of things.

For example if there is some other unrelated predecessor of
the merge point,  we could split the merge point so that
the then/else blocks first branch to an empty block
and then to the merge point, and then we'd be able to speculate
the then/else code.

But if we'd instead simply start at the divergence point,
and look for the merge point, then we'll just natively support this case.

There's also the fact that `SpeculativelyExecuteBB()` already does
just that, but only if there is a single block to speculate,
and with a much more restrictive cost model.
But that also means we have code duplication.

Now, sadly, while this is as much NFCI as possible,
there is just no way to cleanly migrate to
the proper implementation. The results *are* going to be different
somewhat because of various phase ordering effects and SimplifyCFG
block iteration strategy.

[NFC][SimplifyCFG] Autogenerate checklines in a few tests being affected by upcoming change

[MLIR][Presburger] Simplify checkExplicitRepresentation

This also gets rid of a clang-tidy warning.

Reviewed By: Groverkss

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