There was a bug where some of the OpOperands needed in the replacement op were not in scope.

It does not matter where the replacement op is inserted. Any insertion point is OK as long as there are no dominance errors. In the worst case, the newly inserted op will bufferize out-of-place. This is no worse than not eliminating the InitTensorOp at all.

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

The formatter specialization tests were placed in the wrong
subdirectory. This moves them to the proper place.

I had a look at the changes since the last release and updated the
release notes with interesting changes.

It seems this time the release notes were already rather up to date :-)

If there are more interesting changes, please let me know and I'll
update the patch. I'd like to commit these changes latest next weekend
so they land before branching the 14.0 release.

I've added most active libc++ contributors. If I forgot anybody please add them.

Reviewed By: Quuxplusone, ldionne, philnik, #libc

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

Also reimplement `std-bufferize` in terms of BufferizableOpInterface-based bufferization. The old `std.select` bufferization pattern is no longer needed and deleted.

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

This removes the remaining dependence on LoopVectorizationCostModel from
buildScalarSteps and is required so it can be moved out of ILV.

It also improves allows us to remove a few unneeded instructions.

Reviewed By: Ayal

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

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

This should have been done as part of D118483.

The bufferization of arith.constant ops is also switched over to BufferizableOpInterface-based bufferization. The old implementation is deleted. Both implementations utilize GlobalCreator, now renamed to just `getGlobalFor`.

GlobalCreator no longer maintains a set of all created allocations to avoid duplicate allocations of the same constant. Instead, `getGlobalFor` scans the module to see if there is already a global allocation with the same constant value.

For compatibility reasons, it is still possible to create a pass that bufferizes only `arith.constant`. This pass (createConstantBufferizePass) could be deleted once all users were switched over to One-Shot bufferization.

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

gep(x, undef) carries the provenance of x, so we can't replace it with any
pointer like undef.
This leaves room for improvement for the poison case, but that's currently
not possible as the demanded bits API doesn't distinguish between undef &
poison bits.

Fixes #44790

We don't need to support the empty/tombstone key section index.

My x86-64 lld executable is 18KiB smaller.

Similar to D116143. My x86-64 lld executable is 20+KiB smaller.

We already have an ISD opcode for the more general GREV/GREVI
instructon. We can just use it with the encoding that corresponds
to the behavior of brev8. This is similar to what we do for orc.b
where we use the GORC ISD opcode.

Especially placing W instructions/patterns near their non-W versions.

- Sort new checks by check name
- Sort changes to existing checks by check name
- Add docs for changes to readability-simplify-boolean-expr
- Move check changes from "Improvements to clang-tidy" to
  "Changes in existing checks" section

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

In my x86-64 lld, .text is -3.08Ki smaller.

AVR is baremetal environment, so the avr-libc does not support
'__cxa_atexit()'.

Reviewed By: MaskRay

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

Reviewed By: MaskRay

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

Move it before others.

`symbols` is used frequently. Moving it before others can decrease offsets.

As @mstorsjo wrote in https://reviews.llvm.org/D117945#inline-1132920 :

> This change seems to have broken one aspect: When doing `ninja
install` I now get a warning saying `Error copying file "libomp.dll" to
"libiomp5md.dll".`, and `libiomp5md.dll` isn't installed.
>
> I believe the reason is that the inline cmake snippet is written to
`runtime/src/cmake_install.cmake` and then executed on install, but on
install, `${CMAKE_INSTALL_BINDIR}` isn't set (as `GNUInstallDirs` isn't
included there). Should this maybe expand `${CMAKE_INSTALL_BINDIR}`
right here instead of deferring it to the install cmake, or what's the
right course of action?

I agree that is the right course of action. We also agreed to restore the `CMAKE_INSTALL_PREFIX` that was there before, too.

Reviewed By: mstorsjo

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

https://reviews.llvm.org/D117436 caused a build failure
due to this error.

Tested:
ninja docs-llvm-libc builds

Reviewed By: abrachet

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

Remove copy and copy assignment rather than have them as private declarations.
They are superfluous given the move and move assignment.

As a drive-by, also specialize `std::hash` without reopening `namespace std`.

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

* `RelocationBaseSection::addReloc` increases `numRelativeRelocs`, which
  duplicates the work done by RelocationSection<ELFT>::writeTo.
* --pack-dyn-relocs=android has inappropropriate DT_RELACOUNT.
  AndroidPackedRelocationSection does not necessarily place relative relocations
  in the front and DT_RELACOUNT might cause semantics error (though our
  implementation doesn't and Android bionic doesn't use DT_RELACOUNT anyway.)

Move `llvm::partition` to a new function `partitionRels` and compute
`numRelativeRelocs` there. Now `RelocationBaseSection::addReloc` is trivial and
can be moved to the header to enable inlining.

The rest of DynamicReloc and `-z combreloc` handling is moved to the
non-template `RelocationBaseSection::computeRels` to decrease code size. My
x86-64 lld executable is 44+KiB smaller.

While here, rename `sort` to `combreloc`.

Noticed in https://github.com/msys2/MINGW-packages/pull/10567.

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

As discussed in D118021 <https://reviews.llvm.org/D118021>, `clang -m32` on
Solaris/sparcv9 currently incorrectly doesn't inline atomics on 8-byte
operands, unlike `gcc`.  With the workaround in that patch in place, we're
left with may undefined references to `__sync_val_compare_and_swap_8`,
which isn't provided by `libatomic`.  This reference is due to the use of
`__sync_val_compare_and_swap` in `sanitizer_atomic_clang.h`'s
`atomic_compare_exchange_strong`.  As is already done in
`scudo/standalone/atomic_helpers.h`, using `__atomic_compare_exchange`
instead avoids this problem.

Tested on `sparcv9-sun-solaris2.11`, `amd64-pc-solaris2.11`, and
`x86_64-pc-linux-gnu`.

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