This commit adds a pattern that expands `math.roundeven` into
`math.round` + some ops from `arith`. This is needed to be able to run
`math.roundeven` in a vectorized manner.

Reviewed By: jpienaar

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

This test is heavy on test resources and involves moving a large 2GB+ file
across an ssh connection when testing on remote devices. Exclude all tests
except for macOS testing (on host). Remote device testing for macOS may
eventually cause a problem on macOS as well w/o better handling of tests
that require more resource/time than we currently handle.
    Introduced by:
        https://reviews.llvm.org/D146189
    Subsequent exclusion of all but darwin by:
        https://reviews.llvm.org/D147094
    Subsequent exclusion of tvOS and watchOS by:
        https://reviews.llvm.org/D147502
    Subsequent exclusion of all but macOS...

rdar://107570309

Reviewed By: yln, thetruestblue

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

As obvious from the paper's title this is an LWG issue and thus retroactively
applied to C++20. This change may the output for certain code points:
1 Considers 8477 extra codepoints as having a width 2 (as of Unicode 15)
  (mostly Tangut Ideographs)
2 Change the width of 85 unassigned code points from 2 to 1
3 Change the width of 8 codepoints (in the range U+3248 CIRCLED NUMBER
  TEN ON BLACK SQUARE ... U+324F CIRCLED NUMBER EIGHTY ON BLACK
  SQUARE) from 2 to 1, because it seems questionable to make an exception
  for those without input from Unicode

Note that libc++ already uses Unicode 15, while the Standard requires Unicode 12.
(The last time I checked MSVC STL used Unicode 14.)

So in practice the only notable change is item 3.

Implements
  P2675 LWG3780: The Paper
  format's width estimation is too approximate and not forward compatible

Benchmark before these changes
--------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
--------------------------------------------------------------------
BM_ascii_text<char>             3928 ns         3928 ns       178131
BM_unicode_text<char>          75231 ns        75230 ns         9158
BM_cyrillic_text<char>         59837 ns        59834 ns        11529
BM_japanese_text<char>         39842 ns        39832 ns        17501
BM_emoji_text<char>             3931 ns         3930 ns       177750
BM_ascii_text<wchar_t>          4024 ns         4024 ns       174190
BM_unicode_text<wchar_t>       63756 ns        63751 ns        11136
BM_cyrillic_text<wchar_t>      44639 ns        44638 ns        15597
BM_japanese_text<wchar_t>      34425 ns        34424 ns        20283
BM_emoji_text<wchar_t>          3937 ns         3937 ns       177684

Benchmark after these changes
--------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
--------------------------------------------------------------------
BM_ascii_text<char>             3914 ns         3913 ns       178814
BM_unicode_text<char>          70380 ns        70378 ns         9694
BM_cyrillic_text<char>         51889 ns        51877 ns        13488
BM_japanese_text<char>         41707 ns        41705 ns        16723
BM_emoji_text<char>             3908 ns         3907 ns       177912
BM_ascii_text<wchar_t>          3949 ns         3948 ns       177525
BM_unicode_text<wchar_t>       64591 ns        64587 ns        10649
BM_cyrillic_text<wchar_t>      44089 ns        44078 ns        15721
BM_japanese_text<wchar_t>      39369 ns        39367 ns        17779
BM_emoji_text<wchar_t>          3936 ns         3934 ns       177821

Benchmarks without "if(__code_point < (__entries[0] >> 14))"
--------------------------------------------------------------------
Benchmark                          Time             CPU   Iterations
--------------------------------------------------------------------
BM_ascii_text<char>             3922 ns         3922 ns       178587
BM_unicode_text<char>          94474 ns        94474 ns         7351
BM_cyrillic_text<char>         69202 ns        69200 ns        10157
BM_japanese_text<char>         42735 ns        42692 ns        16382
BM_emoji_text<char>             3920 ns         3919 ns       178704
BM_ascii_text<wchar_t>          3951 ns         3950 ns       177224
BM_unicode_text<wchar_t>       81003 ns        80988 ns         8668
BM_cyrillic_text<wchar_t>      57020 ns        57018 ns        12048
BM_japanese_text<wchar_t>      39695 ns        39687 ns        17582
BM_emoji_text<wchar_t>          3977 ns         3976 ns       176479

This optimization does carry its weight for the Unicode and Cyrillic
test. For the Japanese tests the gains are minor and for emoji it seems
to have no effect.

Reviewed By: ldionne, tahonermann, #libc

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

When --threads= is unspecified, we set it to
`parallel::strategy.compute_thread_count()`, which uses
sched_getaffinity (Linux)/cpuset_getaffinity (FreeBSD)/std::thread::hardware_concurrency (others).
With extensive testing on many machines (many configurations from
{aarch64,x86-64} x {Linux,FreeBSD,Windows} x allocators(native,mimalloc,rpmalloc) combinations)
with varying workloads, we discovered that when the concurrency is larger than
16, the linking process is slower than using --threads=16 due to parallelism
overhead outweighs optimizations. This is particularly harmful for machines with
many cores or when the link job competes with other jobs.

Cap parallel::strategy when --threads= is unspecified.
For some workloads changing the concurrency from 8 to 16 has nearly no improvement.

--thinlto-jobs= is unchanged since ThinLTO backend compiles are embarrassingly
parallel.

Link: https://discourse.llvm.org/t/avoidable-overhead-from-threading-by-default/69160

Reviewed By: peter.smith, andrewng

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

Reviewed By: ldionne, #libc

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

As pointed out in
https://discourse.llvm.org/t/undeterministic-thin-index-file/69985, the
block count added to distributed ThinLTO index files breaks incremental
builds on ThinLTO - if any linked file has a different number of BBs,
then the accumulated sum placed in the index files will change, causing
all ThinLTO backend compiles to be redone.

The block count is only used for scaling of partial sample profiles, and
was added in D80403 for D79831.

This patch simply removes this field from the index files of non partial
sample profile compiles, which is NFC on the output of the compiler.

We subsequently need to see if this can be removed for partial sample
profiles without signficant performance loss, or redesigned in a way
that does not destroy caching.

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

Fixed issue where {tu,cu}-index fixup code for DWARF5 that would report an error when
fixup map is empty. Which is the case when seciton(s) are not over 4GB or
--manaully-generate-unit-index is not specified

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

Defaults to ON for x86_64 && (Linux | Darwin).

If enabled, checks that /proc/self/map_files is readable. Some systems are configured so that getdents fails with EPERM.

Reviewed By: rafauler

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

Review: https://reviews.llvm.org/D147572

We were treating vXi8 multiply as the sum of a trunc(mul(extend(),extend())) which diverged from the costs from llvm-mcaonce we extended beyond legal types

Use a modified version of the D103695 script to determine more accurate throughput/latency/codesize/size-latency cost estimates

Helps address some of the regressions identified in D148806

In https://reviews.llvm.org/D141285 the optional definitions of `HWCAP`
macros were moved to before their usage. However, they were also moved
to before the inclusion of system headers which can optionally define
them. If any of those system headers then actually defined any of the
`HWCAP` macros, it would result in a redefinition error.

Move the system header includes to just before the optional definitions,
to avoid this problem.

Reviewed By: ilinpv

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

We only want to make PCH imports visible once for the the TU, not
repeatedly after every subsequent import. This causes some incorrect
behaviour with submodule visibility, and causes us to get extra module
dependencies in the scanner. So far I have only seen obviously incorrect
behaviour when building with -fmodule-name to cause a submodule to be
textually included when using the PCH, though the old behaviour seems
wrong regardless.

rdar://107449644

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

This reverts commit d81cdb49.

This refactoring was waiting on converting LLVM to C++17.

Leave StringView.h and cleanup around for subsequent cleanup.

Additional fixes for missing std::string_view conversions for MSVC.

Reviewed By: MaskRay, DavidSpickett, ayzhao

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

ExpandOpsPass could only be configured via command line flags. Updated
to allowed constructing using the specified Options structure.

Reviewed By: NatashaKnk

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

This patch adds new `-print-timing` option to `clang-scan-deps`. It measures the wall and process time taken to scan dependencies for the compilation database. This provides more representative data compared to measuring the timing for the whole tool invocation, since that includes parsing and generating JSON files, which can be significant for larger inputs.

Reviewed By: akyrtzi

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

The current expand pattern for `math.round` does not handle the
special values -0.0, +-inf, and +-nan correctly. It also does not
properly handle values with magnitude |x| >= 2^23. Lastly, the pattern
generates invalid IR when the input to `math.round` is a vector. This
patch fixes these issues.

Reviewed By: rsuderman

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

Given two adds that are both nuw, they will still be nuw after being
reassociated. (They only increase in value and at no point wrap).
https://alive2.llvm.org/ce/z/JrYM6H

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

Add support for array section with constant lower or upper bound.
The current lowering will trigger a TODO when the array is assumed size
or if the lower or upper bound is a variable.

Depends on D148721

Reviewed By: razvanlupusoru, jeanPerier

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

I meant to fold this into cb7dffdc but
failed to do so.

Update the Zvk support from 0.3.x to 0.5.1, tracking the extension as
documented in
<https://github.com/riscv/riscv-crypto/releases/download/v20230407/riscv-crypto-spec-vector.pdf>.

- Zvkb is split into Zvbb and Zvbc
- Zvbc (vector carryless multiply) requires 64 bit elements (Zve64x)
- Use the extension descriptions from the specification for Zvbb/Zvbc
- Zvkt is introduced (no instructions, but adds an attribute and macro)
- Zvkn and Zvks both imply Zvkt
- Zvkng and Zvksg are introduced, adding Zvkg (GMAC) to Zvkn and Zvks
- In Zvbb, add vrev.v, vclz.v, vctz.v, vcpop.v, vwsll.{vv,vx,vi}

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

In that case, the cost for i32 and i64 should be 1 (a single EXTR
instruction). For v4i32 and v2i64 it should be 3 (USHR + SHL + ORR).

Other sizes smaller than 64 bits require an extra instruction for
conversion to i32/i64.

This recovers a SLP regression revealed by D140392.

Reviewed By: dmgreen

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

Add C++ 20 style starts_with to replace StringView::startsWith in
LLVMDemangle. Due to library layering (LLVMSupport depends on
LLVMDemangle), we add the utility header under llvm/Demangle, instead of
llvm/ADT or llvm/Support.

Modify this in libcxxabi, then copy this over to llvm.

Reviewed By: MaskRay, #libc_abi, phosek

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

This adds an option to emit the command line -mattr/-march into the
attributes of an object file. This can be useful to get objdump to
disassemble instructions that aren't in the base without forcing
users to add a .attribute to the assembly file.

The binutils assembler does this by default.

Similar option exists for ARM. I will wire it to a clang option in
another patch. Similar to https://reviews.llvm.org/D31813

Reviewed By: asb, kito-cheng

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

BitsRecTy objects are uniqued based on size. If the sizes are equal, then
the BitsRecTy objects are the same objects. We can use the base class
implementation that checks for pointer equality.

Reviewers: ldionne, philnik, EricWF

Reviewed By: EricWF

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

See D148809

This reverts commit da68d216.

This change is correct, but left a `config->threadCount` use that is error-prone
and may harm performance when parallel::strategy.compute_thread_count() > 16.

This fix a regression introduced by commit 5db12eca

Fixes the compilation failure reported by libc-x86_64-debian-gcc-fullbuild-dbg:

.../libc/src/__support/UInt.h:26:31: note: ‘struct __llvm_libc::cpp::UInt<192>’ has no user-provided default constructor
   26 | template <size_t Bits> struct UInt {
      |                               ^~~~
.../libc/src/__support/UInt.h:38:13: note: constructor is not user-provided because it is explicitly defaulted in the class body
   38 |   constexpr UInt() = default;

The utility functions takes a region and makes it isolated from above
by appending to the entry block arguments that represent the captured
values and replacing all uses of the captured values within the region
with the newly added arguments. The captures values are returned.

The utility function also takes an optional callback that allows
cloning operations that define the captured values into the region
during the process of making it isolated from above. The cloned value
is no longer a captured values. The operands of the operation are then
captured values. This is done transitively allow cloning of a DAG of
operations into the region based on the callback.

Reviewed By: jpienaar

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

There are 2 problems in the cost estimation for buildvector/gather.
1. If the buildvector/gather node is the same as another one node, need
   to estimate the cost of this node as 0.
2. The cost of inserting float point register to non-poison vector is
   not 0, it should not be considered free.

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

Fix https://github.com/llvm/llvm-project/issues/62247

D131057 added `bArg` and `BArg` in the `AsLongLong` label in
`FormatSpecifier::hasValidLengthModifier`, but missed the `AsLong` label,
therefore `%llb` is allowed while `%lb` (e.g. `printf("%lb", (long)10)`) has a
spurious warning. Add the missing case labels.

Reviewed By: aaron.ballman, enh

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

When building with the 17.5.0 preview toolset for MSVC and building with
modules, the definition of _addcarry_u64 and _subborrow_u64 seem to
cause issues due to the use of GNU inline semantics. Change the headers
to prefer C++ inline semantics for C++ compilation, falling back to GNU
inlining semantics for C compilation.

This is motivated by https://github.com/microsoft/STL/issues/2520.

Differential Revision: https://reviews.llvm.org/D139749
Reviewed By: fsb4000

This patch defaults the copy constructor and copy operator so it can be
used with __builtin_bit_cast

Reviewed By: sivachandra

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

Extra tests discussed in D147322.

Extra tests discussed in D147322.

Reviewed By: thieta

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