However, whether applications rely on the std::bad_function_call vtable
being in the dylib is still controlled by the ABI macro, since changing
that would be an ABI break.

Also separate preprocessor definitions for whether to use a key function
and whether to use a `bad_function_call`-specific `what` message
(`what` message is mandated by [LWG2233](http://wg21.link/LWG2233)).

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

Reviewed By: nikic

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

In libc++ most of the names are not conforming to the llvm style. Removing the readability-identifier-naming check removes almost all clang-tidy warnings. For example in `<string>` the warning count goes from 1001 warnings down to 7.

Reviewed By: #libc, Mordante, ldionne

Spies: Mordante, Quuxplusone, aheejin, libcxx-commits, carlosgalvezp

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

This patch adds PPC back end optimization to analyze the arguments of a
conditional trap instruction to execute one of the following:
1. Delete it if never trap
2. Replace it if always trap
3. Otherwise keep it

Reviewed By: nemanjai, amyk, PowerPC

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

std::hash returns a 64bit hash code while previously we were using only lower 32 bits which caused hash collision for large workloads.

Reviewed By: wenlei, wlei

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

This allows for using SFINAE partial specialization for DenseMapInfo.
In MLIR, this is particularly useful as it will allow for defining partial
specializations that support all Attribute, Op, and Type classes without
needing to specialize DenseMapInfo for each individual class.

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

This splits tryEvict into a const tryFindEvictionCandidate, which
attempts to find a candidate, and the actual eviction (should the former
be successful)

The newly introduced tryFindEvictionCandidate will move subsequently
into the RegAllocEvictionAdvisor.

RFC: https://lists.llvm.org/pipermail/llvm-dev/2021-November/153639.html

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

We need to avoid directly processing the Bazel config in LLVM's copy of
google/benchmark, which was moved in
https://github.com/llvm/llvm-project/commit/1ee32055ea.

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

This reverts commit e7568b68 and relands
c6f7b720.

The culprit was: missed that libc also had a dependency on one of the
copies of `google-benchmark`

Also opportunistically fixed indentation from prev. change.

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

3d1d8c76 made
DWARFExpression::iterator's Operation member `mutable`. After a few prep
commits, the iterator can instead be made a `const` iterator since no
caller can change the Operation.

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

The only caller of Operation::verify() is DWARFExpression::verify(),
which iterates past the (ephemeral) Operation immediately after.

- Stop setting Operation::Error because the mutation will never be
  observed.
- Change verify() to a static function to be sure all callers are
  updated.

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

[NFC] As part of using inclusive language within the llvm project, this patch
replaces `_myMaster` with `_myLeader` in these testcases.

Reviewed By: ZarkoCA

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

This is to help reduce latency by running longer jobs before shorter ones.

This is part of the replacement of Identifier with StringAttr.

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

This reverts commit c6f7b720.

Some buildbots are failing, will investigate and reland.
Example:
  https://lab.llvm.org/buildbot#builders/138/builds/14067
  https://lab.llvm.org/buildbot#builders/73/builds/20159

under third-party

This change:
- moves the libcxx copy of `google/benchmark` to
`third-party/benchmkark`
- points the 2 uses of the library (libcxx and llvm/utils) to this copy

We picked the licxx copy because it is the most up to date.

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

I'm still seeing random timeouts on green dragon.

LLVM switchop currently only permits i32. Both LLVM IR and MLIR Standard switch permit other integer types leading to an illegal state when lowering an i8 switch from MLIR standard

Reviewed By: mehdi_amini

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

This just cuts down on casts to Operator.

This commit adds a benchmark that tests std::sort on an adversarial inputs,
and uses introsort in std::sort to avoid O(n^2) behavior on adversarial
inputs.

Inputs where partitions are unbalanced even after 2 log(n) pivots have
been selected, the algorithm switches to heap sort to avoid the
possibility of spending O(n^2) time on sorting the input.
Benchmark results show that the intro sort implementation does
significantly better.

Benchmarking results before this change. Time represents the sorting
time required per element:

----------------------------------------------------------------------------------------------------------
Benchmark                                                                Time             CPU   Iterations
----------------------------------------------------------------------------------------------------------
BM_Sort_uint32_QuickSortAdversary_1                                   3.75 ns         3.74 ns    187432960
BM_Sort_uint32_QuickSortAdversary_4                                   3.05 ns         3.05 ns    231211008
BM_Sort_uint32_QuickSortAdversary_16                                  2.45 ns         2.45 ns    288096256
BM_Sort_uint32_QuickSortAdversary_64                                  32.8 ns         32.8 ns     21495808
BM_Sort_uint32_QuickSortAdversary_256                                  132 ns          132 ns      5505024
BM_Sort_uint32_QuickSortAdversary_1024                                 498 ns          497 ns      1572864
BM_Sort_uint32_QuickSortAdversary_16384                               3846 ns         3845 ns       262144
BM_Sort_uint32_QuickSortAdversary_262144                             61431 ns        61400 ns       262144
BM_Sort_uint64_QuickSortAdversary_1                                   3.93 ns         3.92 ns    181141504
BM_Sort_uint64_QuickSortAdversary_4                                   3.10 ns         3.09 ns    222560256
BM_Sort_uint64_QuickSortAdversary_16                                  2.50 ns         2.50 ns    283639808
BM_Sort_uint64_QuickSortAdversary_64                                  33.2 ns         33.2 ns     21757952
BM_Sort_uint64_QuickSortAdversary_256                                  132 ns          132 ns      5505024
BM_Sort_uint64_QuickSortAdversary_1024                                 478 ns          477 ns      1572864
BM_Sort_uint64_QuickSortAdversary_16384                               3932 ns         3930 ns       262144
BM_Sort_uint64_QuickSortAdversary_262144                             61646 ns        61615 ns       262144

Benchmarking results after this change:

----------------------------------------------------------------------------------------------------------
Benchmark                                                                Time             CPU   Iterations
----------------------------------------------------------------------------------------------------------
BM_Sort_uint32_QuickSortAdversary_1                                   6.31 ns         6.30 ns    107741184
BM_Sort_uint32_QuickSortAdversary_4                                   4.51 ns         4.50 ns    158859264
BM_Sort_uint32_QuickSortAdversary_16                                  3.00 ns         3.00 ns    223608832
BM_Sort_uint32_QuickSortAdversary_64                                  44.8 ns         44.8 ns     15990784
BM_Sort_uint32_QuickSortAdversary_256                                 69.0 ns         68.9 ns      9961472
BM_Sort_uint32_QuickSortAdversary_1024                                 118 ns          118 ns      6029312
BM_Sort_uint32_QuickSortAdversary_16384                                175 ns          175 ns      4194304
BM_Sort_uint32_QuickSortAdversary_262144                               210 ns          210 ns      3407872
BM_Sort_uint64_QuickSortAdversary_1                                   6.75 ns         6.73 ns    103809024
BM_Sort_uint64_QuickSortAdversary_4                                   4.53 ns         4.53 ns    160432128
BM_Sort_uint64_QuickSortAdversary_16                                  2.98 ns         2.97 ns    234356736
BM_Sort_uint64_QuickSortAdversary_64                                  44.3 ns         44.3 ns     15990784
BM_Sort_uint64_QuickSortAdversary_256                                 69.2 ns         69.2 ns     10223616
BM_Sort_uint64_QuickSortAdversary_1024                                 119 ns          119 ns      6029312
BM_Sort_uint64_QuickSortAdversary_16384                                173 ns          173 ns      4194304
BM_Sort_uint64_QuickSortAdversary_262144                               212 ns          212 ns      3407872

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

The return type of the deleted functions doesn't match the synopsis in
the standard.

Reviewed By: #libc, ldionne

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

This allows tests to tell if they're running natively.

Those tests are libcxxabi/test/native/arm-linux-eabi.
Which were running on Linaro's bots but became unsupported
when we switched to the runtimes build.

Reviewed By: #libc_abi, phosek

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

The string is known to be long since __grow_by unconditionally calls
__set_long_cap().

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

For now I've just changed the code to only return true from
AArch64ISelLowering::hasAndNot if the vector is fixed-length.
Once we have the right patterns or DAG combines to use bic/bif
we can also enable this for SVE.

Test added here:

  CodeGen/AArch64/vselect-constants.ll

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

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

Reviewed By: #libc, ldionne

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

[NFC] As part of using inclusive language within the llvm project and to
match the renamed master branch, this patch replaces master with main in
`convert_arm_neon.py`.

Reviewed By: kristof.beyls

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

The new test started failing on bots with:

CHECK failed: tsan_rtl.cpp:327 "((addr + size)) <= ((TraceMemEnd()))"
   (0xf06200e03010, 0xf06200000000) (tid=4073872)

https://lab.llvm.org/buildbot#builders/179/builds/1761

This is a latent bug in aarch64 virtual address space layout,
there is not enough address space to fit traces for all threads.
But since the trace space is going away with the new tsan runtime
(D112603), disable the test.

Reviewed By: melver

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

Use of gethostent provokes caching of some resources inside of libc.
They are freed in __libc_thread_freeres very late in thread lifetime,
after our ThreadFinish. __libc_thread_freeres calls free which
previously crashed in malloc hooks.
Fix it by setting ignore_interceptors for finished threads,
which in turn prevents malloc hooks.

Reviewed By: melver

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

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

This patch moves the logic to clone and check a new chunk into a new
function, to allow re-use in a follow-up patch that implements parallel
reductions.

Reviewed By: dblaikie

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

The file follows the LSP syntax, so we're intentially deviating
from the LLVM coding standard.

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