Changes

[DebugInfo] Error if unsupported address size detected in line table

Prior to this patch, if a DW_LNE_set_address opcode was parsed with an
address size (i.e. with a length after the opcode) of anything other 1,
2, 4, or 8, an llvm_unreachable would be hit, as the data extractor does
not support other values. This patch introduces a new error check that
verifies the address size is one of the supported sizes, in common with
other places within the DWARF parsing.

This patch also fixes calculation of a generated line table's size in
unit tests. One of the tests in this patch highlighted a bug introduced
in 1271cde4745, when non-byte operands were used as arguments for
extended or standard opcodes.

Reviewed by: dblaikie

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

[llvm-ar] Simplify Windows comparePaths NFCI

Replace use of widenPath in comparePaths with UTF8ToUTF16. widenPath
does a lot more than just conversion from UTF-8 to UTF-16. This is not
necessary for CompareStringOrdinal and could possibly even cause
problems.

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

[OpenMP] Lower taskyield using OpenMP IR Builder

This is similar to D69828.

Special codegen for enclosing untied tasks is still done in clang.

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

llvm/cmake/config.guess: add support for riscv32 and  riscv64

Summary: LLVM configuration fails with 'unable to guess system type' on riscv64.
Add support for detecting riscv32 and riscv64 systems.

Patch by Gokturk Yuksek (gokturk)
Reviewers: erichkeane, rengolin, mgorny, aaron.ballman, beanz, luismarques
Reviewed By: luismarques
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D68899

[X86][SSE] lowerShuffleAsBitRotate - lower to vXi8 shuffles to ROTL on pre-SSSE3 targets

Without PSHUFB we are better using ROTL (expanding to OR(SHL,SRL)) than using the generic v16i8 shuffle lowering - but if we can widen to v8i16 or more then the existing shuffles are still the better option.

REAPPLIED: Original commit rG11c16e71598d was reverted at rGde1d90299b16 as it wasn't accounting for later lowering. This version emits ROTLI or the OR(VSHLI/VSRLI) directly to avoid the issue.

[lldb] Print result when expect_expr unexpectedly succeeds

[clang][DeclPrinter] Implement visitors for {TemplateType,NonTypeTemplate}Parms

Reviewers: sammccall, hokein

Subscribers: kristof.beyls, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

[clang][Index] Introduce a TemplateParm SymbolKind

Summary:
Currently template parameters has symbolkind `Unknown`. This patch
introduces a new kind `TemplateParm` for templatetemplate, templatetype and
nontypetemplate parameters.

Also adds tests in clangd hover feature.

Reviewers: sammccall

Subscribers: kristof.beyls, ilya-biryukov, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

[libc++] span: Fix incorrect static asserts

The static asserts in span<T, N>::front() and span<T, N>::back() are
incorrect as they may be triggered from valid code due to evaluation
of a never taken branch:

    span<int, 0> foo;
    if (!foo.empty()) {
        auto x = foo.front();
    }

The problem is that the branch is always evaluated by the compiler,
creating invalid compile errors for span<T, 0>.

Thanks to Michael Schellenberger Costa for the patch.

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

[test][DebugInfo] Fix signed/unsigned comparison problem in test

This caused build bot failures:
http://lab.llvm.org:8011/builders/ppc64le-lld-multistage-test/builds/8568/

[Driver][RISCV] Add RedHat Linux RISC-V triple

Summary: Adds the RedHat Linux triple to the list of 64-bit RISC-V triples.
Without this the gcc libraries wouldn't be found by clang on a redhat/fedora
system, as the search list included `/usr/lib/gcc/riscv64-redhat-linux-gnu`
but the correct path didn't include the `-gnu` suffix.

Reviewers: lenary, asb, dlj
Reviewed By: lenary
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74399

[clang-tools-extra] fix the check for if '-latomic' is necessary

Summary:
The CheckAtomic module performs two tests to determine if passing
'-latomic' to the linker is required: one for 64-bit atomics, and
another for non-64-bit atomics. clangd only uses the result from
HAVE_CXX_ATOMICS64_WITHOUT_LIB. This is incomplete because there are
uses of non-64-bit atomics in the code, such as the ReplyOnce::Replied
of type std::atomic<bool> defined in clangd/ClangdLSPServer.cpp.

Fix by also checking for the result of HAVE_CXX_ATOMICS_WITHOUT_LIB.

See also: https://reviews.llvm.org/D68964

Reviewers: ilya-biryukov, nridge, kadircet, beanz, compnerd, luismarques
Reviewed By: luismarques
Tags: #clang
Differential Revision: https://reviews.llvm.org/D69869

[AArch64] Add BIT/BIF support.

This patch added generation of SIMD bitwise insert BIT/BIF instructions.
In the absence of GCC-like functionality for optimal constraints satisfaction
during register allocation the bitwise insert and select patterns are matched
by pseudo bitwise select BSP instruction with not tied def.
It is expanded later after register allocation with def tied
to BSL/BIT/BIF depending on operands registers.
This allows to get rid of redundant moves.

Reviewers: t.p.northover, samparker, dmgreen

Reviewed By: dmgreen

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

Reenable "Always import constants" after compile time fixes

Summary:
Reenables importing of constants by default, which was disabled in
D73724 due to excessive thin link times. These inefficiencies were
fixed in D73851.

I re-measured thin link times for a number of binaries that had compile
time explosions with importing of constants previously and confirmed
they no longer have any notable increases with it enabled.

Reviewers: wmi, evgeny777

Subscribers: hiraditya, arphaman, llvm-commits

Tags: #llvm

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

[clangd] Add tracer to the rename workflow, NFC

Reviewers: kbobyrev

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, usaxena95, cfe-commits

Tags: #clang

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

Move update_cc_test_checks.py tests to clang

Having tests that depend on clang inside llvm/ are not a good idea since
it can break incremental `ninja check-llvm`.

Fixes https://llvm.org/PR44798

Reviewed By: lebedev.ri, MaskRay, rsmith
Differential Revision: https://reviews.llvm.org/D74051

[clangd] Update the CompletionItemKind.

Summary: Fix some FIXMEs.

Reviewers: kadircet

Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, usaxena95, cfe-commits

Tags: #clang

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

Revert "[clang-tools-extra] fix the check for if '-latomic' is necessary"

This reverts commit 1d40c4150630729a9c1ce5119a8027dac93a5b2d.
This seemed to have caused build failures on ARM/AArch64.

[libc++] Remove unnecessary typenames from std/numerics/c.math/abs.pass.cpp

There are some unnecessary typenames in std/numerics/c.math/abs.pass.cpp;
e.g. they're not in a dependent context.

Patch by Bryce Adelstein Lelbach

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

Fix line endings produced by update_cc_test_checks.py

Use the same appraoch as update_llc_test_checks.py to always write \n
line endings. This should fix the Windows buildbots.

[ADT] Support BitVector as a key in DenseSet/Map

This patch adds DenseMapInfo<> support for BitVector and SmallBitVector.

This is part of https://reviews.llvm.org/D71775, where a BitVector is used as a thread affinity mask.

[clang-scan-deps] Switch to using a ThreadPool

Use a ThreadPool instead of plain std::threads in clang-scan-deps.
This is needed to further support https://reviews.llvm.org/D71775.

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

[Support] On Windows, ensure hardware_concurrency() extends to all CPU sockets and all NUMA groups

The goal of this patch is to maximize CPU utilization on multi-socket or high core count systems, so that parallel computations such as LLD/ThinLTO can use all hardware threads in the system. Before this patch, on Windows, a maximum of 64 hardware threads could be used at most, in some cases dispatched only on one CPU socket.

== Background ==
Windows doesn't have a flat cpu_set_t like Linux. Instead, it projects hardware CPUs (or NUMA nodes) to applications through a concept of "processor groups". A "processor" is the smallest unit of execution on a CPU, that is, an hyper-thread if SMT is active; a core otherwise. There's a limit of 32-bit processors on older 32-bit versions of Windows, which later was raised to 64-processors with 64-bit versions of Windows. This limit comes from the affinity mask, which historically is represented by the sizeof(void*). Consequently, the concept of "processor groups" was introduced for dealing with systems with more than 64 hyper-threads.

By default, the Windows OS assigns only one "processor group" to each starting application, in a round-robin manner. If the application wants to use more processors, it needs to programmatically enable it, by assigning threads to other "processor groups". This also means that affinity cannot cross "processor group" boundaries; one can only specify a "preferred" group on start-up, but the application is free to allocate more groups if it wants to.

This creates a peculiar situation, where newer CPUs like the AMD EPYC 7702P (64-cores, 128-hyperthreads) are projected by the OS as two (2) "processor groups". This means that by default, an application can only use half of the cores. This situation could only get worse in the years to come, as dies with more cores will appear on the market.

== The problem ==
The heavyweight_hardware_concurrency() API was introduced so that only *one hardware thread per core* was used. Once that API returns, that original intention is lost, only the number of threads is retained. Consider a situation, on Windows, where the system has 2 CPU sockets, 18 cores each, each core having 2 hyper-threads, for a total of 72 hyper-threads. Both heavyweight_hardware_concurrency() and hardware_concurrency() currently return 36, because on Windows they are simply wrappers over std::thread::hardware_concurrency() -- which can only return processors from the current "processor group".

== The changes in this patch ==
To solve this situation, we capture (and retain) the initial intention until the point of usage, through a new ThreadPoolStrategy class. The number of threads to use is deferred as late as possible, until the moment where the std::threads are created (ThreadPool in the case of ThinLTO).

When using hardware_concurrency(), setting ThreadCount to 0 now means to use all the possible hardware CPU (SMT) threads. Providing a ThreadCount above to the maximum number of threads will have no effect, the maximum will be used instead.
The heavyweight_hardware_concurrency() is similar to hardware_concurrency(), except that only one thread per hardware *core* will be used.

When LLVM_ENABLE_THREADS is OFF, the threading APIs will always return 1, to ensure any caller loops will be exercised at least once.

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

Revert "Reland D74436 "Change clang option -ffp-model=precise to select ffp-contract=on""

This reverts commit 0a1123eb43f945593b26dd037490e0c909fa3c4f.
Want to revert this because it's causing trouble for PowerPC
I also fixed test fp-model.c which was looking for an incorrect error message

add type_traits include as required for std::integral_constant

Reverting D73027 [DependenceAnalysis] Dependecies for loads marked with "ivnariant.load" should not be shared with general accesses(PR42151).

[Driver] Rename AddGoldPlugin to addLTOOptions. NFC

AddGoldPlugin does more than adding `-plugin path/to/LLVMgold.so`.
It works with lld and GNU ld, and adds other LTO options.
So AddGoldPlugin is no longer a suitable name.

Reviewed By: tejohnson

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

Fix compilation breakage introduced by 8404aeb56a73ab24f9b295111de3b37a37f0b841.

Also fix BitVector unittest failure when DLLVM_ENABLE_ASSERTIONS are OFF, introduced by d110c3a9f5253c4d94c10299c61fbbb33edab7db.