[AArch64] Reassociate integer extending reductions to pairwise addition.

Given an (integer) vecreduce, we know the order of the inputs does not matter.
We can convert UADDV(add(zext(extract_lo(x)), zext(extract_hi(x)))) into
UADDV(UADDLP(x)). This can also happen through an extra add, where we transform
UADDV(add(y, add(zext(extract_lo(x)), zext(extract_hi(x))))).

This makes sure the same thing happens signed cases too, which requires adding
a new SADDLP node.

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

[clang-format] Revert a feature in RemoveBracesLLVM

Revert the handling of a single-statement block that gets wrapped.

See issue #53543.

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

[compiler-rt][lsan] Increase libdl_deadlock test timeout

We (Linaro) still have the occasional failure here due
to high load on a shared buildbot machine.

We are looking into general soloutions but perhaps this
will help in the meantime.

[mlir][NFC] Fully qualify a default C++ string in Pattern.cpp

[fir] Add fir.array_access op

The `array_access` provides a reference to a single element from an array
value. This is *not* a view in the immutable array, otherwise it couldn't
be stored to. It can be see as a logical copy of the element and its
position in the array. This reference can be written to and modified without
changing the original array.

The `array_access` operation is used to fetch the memory reference of an
element in an array value.

```fortran
      real :: a(n,m)
      ...
      ... a ...
      ... a(r,s+1) ...
```

One can use `fir.array_access` to recover the implied memory reference to
the element `a(i,j)` in an array expression `a` as shown above. It can also
be used to recover the reference element `a(r,s+1)` in the second
expression.

```mlir
      %s = fir.shape %n, %m : (index, index) -> !fir.shape<2>
      // load the entire array 'a'
      %v = fir.array_load %a(%s) : (!fir.ref<!fir.array<?x?xf32>>, !fir.shape<2>) -> !fir.array<?x?xf32>
      // fetch the value of one of the array value's elements
      %1 = fir.array_access %v, %i, %j : (!fir.array<?x?xf32>, index, index) -> !fir.ref<f32>
```

More information about `array_access` and other array operations can be
found in flang/docs/FIRArrayOperations.md.

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

Reviewed By: kiranchandramohan, schweitz

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

Co-authored-by: Eric Schweitz <eschweitz@nvidia.com>

[flang] Lower integer constant code for STOP stmt

This patch lower the integer constant code in the STOP statement.

The code is lowered to `arith.constant`.

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

Reviewed By: schweitz, kiranchandramohan

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

[syntax][pseudo] Add Grammar for the clang pseudo-parser

This patch introduces the Grammar class, which is a critial piece for constructing
a tabled-based parser.

As the first patch, the scope is limited to:
  - define base types (symbol, rules) of modeling the grammar
  - construct Grammar by parsing the BNF file (annotations are excluded for now)

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

[flang] Add lowering for integer constant

This patch enables the lowering of integer constant.

The `ScalarExprLowering` class is introduced in `ConvertExpr.cpp` to help
the lowering of expression. This patch adds all the placeholder as well for future
expression lowering with the appropriate TODOs.

Integer constant expression are lowered to `arith.constant` with an integer type corresponding to the kind value.

This patch is in support of D118787

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

Reviewed By: schweitz, kiranchandramohan

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

[clang][Hexagon] Match -lc option more specifically in toolchain test

In https://lab.llvm.org/buildbot/#/builders/185/builds/1341
our bot happened to generate a temporary file path with -lc in
it.

Match with "" around the options so this doesn't happen again.

[VE] Packed v512i32 isel and tests

Reviewed By: kaz7

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

[ConstantFolding] Fold constrained compare intrinsics

The change implements constant folding of ‘llvm.experimental.constrained.fcmp’
and ‘llvm.experimental.constrained.fcmps’ intrinsics.

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

Revert "[compiler-rt][Darwin] Add arm64 to simulator platforms"

This reverts commit a8e5ce76b475a22546090a73c22fa4f83529aa4e.

It looks like older Xcodes' headers don't allow arm64 builds so it was causing
CI failures.

[clang-format] Reserve vectors when the number of items is known beforehand. NFC.

Revert "[SimplifyCFG] Start redesigning `FoldTwoEntryPHINode()`."

Unfortunately, it seems we really do need to take the long route;
start from the "merge" block, find (all the) "dispatch" blocks,
and deal with each "dispatch" block separately, instead of simply
starting from each "dispatch" block like it would logically make sense,
otherwise we run into a number of other missing folds around
`switch` formation, missing sinking/hoisting and phase ordering.

This reverts commit 85628ce75b3084dc0f185a320152baf85b59aba7.
This reverts commit c5fff9095342a792bf4b9a077fe3c3a83c4e566c.
This reverts commit 34a98e1046e3aa55e5f26ab20a15e96b4034d25a.
This reverts commit 1e353f092288309d74d380367aa50bbd383780ed.

[ISEL] Canonicalize STEP_VECTOR to LHS if RHS is a splat.

This helps recognise patterns where we're trying to match STEP_VECTOR
patterns to INDEX instructions that take a GPR for the Start/Step.

The reason for canonicalising this operation to the LHS is
because it will already be canonicalised to the LHS if the RHS
is a constant splat vector.

Reviewed By: paulwalker-arm

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

[AMDGPU] Update two Codegen tests. (NFC)

This change adds a new Codegen test with auto-generated checks and
updates divergence-driven-trunc-to-i1.ll with auto-generated checks.
This is in preparation to D118461 to visualize the Codegen changes.

Remove -Wweak-template-vtables

as it was planned for removal in clang 15 and we're now past the branch point

See https://github.com/llvm/llvm-project/issues/19107

Differential revision: https://reviews.llvm.org/D118762

[flang] add ExtendedValue type helpers and factory::genZeroValue

Add some helpers to get the base type and element type of
fir::ExtendedValue and to test if a fir::ExtendedValue is
a derived type with length parameters.

Add a new helper factory::genZeroValue to generate zero scalar value for
all the numerical types and false for logicals.

These helpers are used only in lowering for now, so add unit tests.

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

[clang-format] Use back() instead of rbegin(). NFC.

[clang-format] Remove unnecessary non-null check and assert instead. NFC.

After a non-eof token, there is at least an eof token.

[mlir] Fix crash in RewriterGen when a `TypeConstraint` is not given an argument

The code assumes that a TypeConstraint in the additional constraints list specifies precisely one argument.
If the user were to not specify any, it'd result in a crash. If given more than one, the additional ones were ignored.

This patch fixes the crash and disallows user errors by adding a check that a single argument is supplied to the TypeConstraint

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

[llvm-jitlink] Add comment to clarify testcase intent.

[llvm-jitlink] Add -alias option, shorten "-define-abs" option to "-abs".

The -alias option can be used to define aliases within a JITDylib. The
immediate motivation is to simplify testing of ORC runtime functions using
existing testcases (e.g. by aliasing dlfcn functions to their ORC-runtime
counterparts, like -alias dlopen=__orc_rt_macho_dlopen). The option is likely
to be useful for testing in general.

The -define-abs option is shortened to -abs for consistency with -alias.

[asan][test] Re-generate asan-check-memaccess-add.ll with update_llc_test_checks.py

* LABEL is important to give a better diagnostic in case a check pattern fails
* Some NOT negative patterns are not effective. NEXT is useful to ensure
  a code sequence has the desired instructions and report a better
  diagnostic if something goes off.
* Since the ABI says the first parameter is in RDI. Replacing the
  pattern `[[REG16:.*]]` with `RDI` should not cause maintenance burden.

Since the test is pretty mechanical, just use update_llc_test_checks.py
to re-generate it. Most functions can use `nounwind` to avoid CFI
directives.

Reviewed By: kstoimenov, vitalybuka

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

[libc++][nfc] Add TEST_HAS_NO_UNICODE_CHARS.

This avoids using an libc++ internal macro in our tests.

Reviewed By: #libc, philnik, ldionne

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

[libc++][ranges][NFC] Test the specializations of `tuple_{size,element}` for ranges.

Also update the synopsis in `<ranges>` to mention the specializations.

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

[BOLT][NFC] Use isInt<> instead of range checks

Summary: Reuse LLVM isInt check

Reviewed By: maksfb

FBD33945182

[RISCV] Remove unused variables. NFC

[BOLT][TEST] Add heatmap.test

Add a basic test for heatmap mode

Reviewed By: maksfb, ayermolo

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

[clang] Mark `trivial_abi` types as "trivially relocatable".

This change enables library code to skip paired move-construction and destruction for `trivial_abi` types, as if they were trivially-movable and trivially-destructible. This offers an extension to the performance fix offered by `trivial_abi`: rather than only offering trivial-type-like performance for pass-by-value, it also offers it for library code that moves values but not as arguments.

For example, if we use `memcpy` for trivially relocatable types inside of vector reallocation, and mark `unique_ptr` as `trivial_abi` (via `_LIBCPP_ABI_ENABLE_UNIQUE_PTR_TRIVIAL_ABI` / `_LIBCPP_ABI_UNSTABLE` / etc.), this would speed up `vector<unique_ptr>::push_back` by 40% on my benchmarks. (Though note that in this case, the compiler could have done this anyway, but happens not to due to the inlining horizon.)

If accepted, I intend to follow up with exactly such changes to library code, including and especially `std::vector`, making them use a trivial relocation operation on trivially relocatable types.

**D50119 and P1144:**

This change is very similar to D50119, which was rejected from Clang. (That change was an implementation of P1144, which is not yet part of the C++ standard.)

The intent of this change, rather than trying to pick a winning proposal for trivial relocation operations, is to extend the behavior of `trivial_abi` in a way that could be made compatible with any such proposal. If P1144 or any similar proposal were accepted, then `trivial_abi`, `__is_trivially_relocatable`, and everything else in this change would be redefined in terms of that.

**Safety:**

It's worth pointing out, specifically, that `trivial_abi` already implies trivial relocatability in a narrow sense: a `trivial_abi` type, when passed by value, has its constructor run in one location, and its destructor run in another, after the type has been trivially relocated (through registers).

Trivial relocatability optimizations could change the number of paired constructor/destructor calls, but this seems unlikely to matter for `trivial_abi` types.

Reviewed By: rsmith

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

[gn build] Port 610979b301c5

[libc++][ranges] Add ranges::in_out_out_result

Add `ranges::in_out_out_result`

Reviewed By: Quuxplusone, Mordante, #libc

Spies: libcxx-commits, mgorny

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

PR45879: Fix assert when constant evaluating union assignment.

Consider the form of the first operand of a class assignment not the
second operand when implicitly starting the lifetimes of union members.
Also add a missing check that the assignment call actually came from a
syntactic assignment, not from a direct call to `operator=`.

[bazel] Port ead1107257e6

[asan][X86] Change some std::string variables to StringRef. NFC

[gn build] (manually) port ded733bd4 (llvm-remark-size-diff)

[ASan] Added intermediate functions between assembly and __asan_report.* to avoid link errors.

Instead of calling asan_report.* directly from assembly code they have been replaced with corresponding asan_report.*_asm function, which call asan_report.*. All asan_report.* are now undefined weak symbols, which allows DSOs to link when z defs is used.

Reviewed By: MaskRay, morehouse

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

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