[ARM] Remove unused declaration RemapAddSubWithFlags

The corresponding function definition was removed by:

  commit e891654a5855a43104a4f3744a754c5e028c03c7
  Author: Evan Cheng <evan.cheng@apple.com>
  Date:   Tue Aug 30 01:34:54 2011 +0000

While we are at it, this patch removes ARMPCLabelIndex, for which the
host compiler issues an unused variable warning.

lldb PlatformDarwinKernel make local filesystem scan lazy

Instead of doing the local filesystem scan for kexts and kernels
when the PlatformDarwinKernel is constructed, delay doing it until
the scan is needed.

Differential Revision: https://reviews.llvm.org/D150621
rdar://109186357

[GVN] Improve PRE on load instructions

This patch implements the enhancement proposed by
https://github.com/llvm/llvm-project/issues/59312.

Suppose we have following code

     v0 = load %addr
     br %LoadBB

  LoadBB:
     v1 = load %addr
     ...

  PredBB:
     ...
     br %cond, label %LoadBB, label %SuccBB

  SuccBB:
     v2 = load %addr
     ...

Instruction v1 in LoadBB is partially redundant, edge (PredBB, LoadBB) is a
critical edge. SuccBB is another successor of PredBB, it contains another load
v2 which is identical to v1. Current GVN splits the critical edge
(PredBB, LoadBB) and inserts a new load in it. A better method is move the load
of v2 into PredBB, then v1 can be changed to a PHI instruction.

If there are two or more similar predecessors, like the test case in the bug
entry, current GVN simply gives up because otherwise it needs to split multiple
critical edges. But we can move all loads in successor blocks into predecessors.

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

[Sparc] Make use of GET_SUBTARGETINFO_MACRO (NFC)

Reviewed By: koakuma

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

[ValueTracking] Add tests for knownbits of `abs`; NFC

Reviewed By: RKSimon

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

[SelectionDAG] Improve `computeKnownBits` implementations of `sdiv` and `udiv`

Add `exact` flag handling for `udiv` and add entire `sdiv` case.

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

[X86] Add tests for `computeKnownBits` of `sdiv` and `udiv`; NFC

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

[ValueTracking] Use `KnownBits::sdiv` for `sdiv` opcode in `computeKnownBits`

We now of an implementation of `KnownBits::sdiv` so we can implement
this case.

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

[ValueTracking] Pass `exact` flag to `KnownBits::udiv` in `computeKnownBits`

This information was previously missing but we can use it for
determining the low-bits.

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

[KnownBits] Improve `KnownBits::udiv`

We can more precisely determine the upper bits doing `MaxNum /
MinDenum` as opposed to only using the MSB.

As well, if the `exact` flag is set, we can sometimes determine some
of the low-bits.

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

[KnownBits] Add implementation for `KnownBits::sdiv`

Can figure out some of the upper bits (similiar to `udiv`) if we know
the sign of the inputs.

As well, if we have the `exact` flag we can sometimes determine some
low-bits.

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

[ValueTracking] Add tests for knownbits of `sdiv` and `udiv`; NFC

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

[ValueTracking] deduce `X * Y != 0` if `LowestKnownBit(X) * LowestKnownBit(Y) != 0`

For `X * Y`, if there exists a subset of `X` and subset of `Y` s.t `sX * sY != 0`,
then `X * Y != 0`.
    - See first proof: https://alive2.llvm.org/ce/z/28C9CG
    - NB: This is why the previous Odd case works.

In knownbits we could exhaustively hunt for such a subset, but
`LSB(X)` and `LSB(Y)` actually works. If `LSB(X) * LSB(Y) != 0`, then
`X * Y != 0`
    - See proof: https://alive2.llvm.org/ce/z/p5wWid

In `isKnownNonZero` we can use this as if the `LowestKnownOne(X) *
LowestKnownOne(Y) != 0`, then `X * Y != 0`, and we don't need to try
and other subsets.

Reviewed By: nikic

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

[ValueTracking] Add tests for deducing `X * Y != 0` if `LSB(X) * LSB(Y) != 0`; NFC

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

Recommit "[InstCombine] Improve bswap optimization" (2nd try)

Issue was an assertion failure due to an unchecked `cast`. Fix is to
check the operator is `BinaryOperator` before cast so that we won't
match `ConstExpr`

Reviewed By: goldstein.w.n, RKSimon

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

[DAGCombiner] Add bswap(logic_op(bswap(x), y)) optimization

This is the implementation of D149782

The patch implements a helper function that matches and fold the following cases in the DAGCombiner:

1. `bswap(logic_op(x, bswap(y))) -> logic_op(bswap(x), y)`
2. `bswap(logic_op(bswap(x), y)) -> logic_op(x, bswap(y))`
3. `bswap(logic_op(bswap(x), bswap(y))) -> logic_op(x, y)` in multiuse case, which still reduces the number of instructions.

The helper function accepts SDValue with BSWAP and BITREVERSE opcode. This patch folds the BSWAP cases and remain the BITREVERSE optimization in the future

Reviewed By: RKSimon, goldstein.w.n

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

[DAGCombiner] Add bswap(logic_op(bswap(x), y)) regression test case; NFC

Fold the following case on SelectionDAG combiner
This patch includes the regression test cases

```
bswap(logic_op(x, bswap(y))) -> logic_op(bswap(x), y)
bswap(logic_op(bswap(x), y)) -> logic_op(x, bswap(y))
bswap(logic_op(bswap(x), bswap(y))) -> logic_op(x, y) (with multiuse)
```

Reviewed By: goldstein.w.n

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

[lli] Reference global @C in global-variable-alignment testcase.

We want to reference both byte-sized globals (@A and @C) to prevent them from
being dead-stripped.

[RISCV] Pre-commit test case from PR62734. NFC

[bazel] Fix build

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

[clang-format] Don't allow template to be preceded by closing brace

This check is similar to the right paren check right below it, but it
doesn't need the overloaded operator check.

This patch prevents brace-initialized objects that are being compared
from being mis-annotated as template parameters.

Fixes https://github.com/llvm/llvm-project/issues/57004

Reviewed By: owenpan, MyDeveloperDay

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

[clang] Convert several smaller OpenMP tests to opaque pointers

Reviewed By: nikic

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

MIPS: allow o32 abi with 64bit CPU and 64 abi with 32bit triple

In general, MIPS support ELF format like
   ELF 32-bit LSB relocatable, MIPS, MIPS64 rel2 version 1 (SYSV)
and Linux's VDSO uses it.

Currently clang stop CMDs like
    clang -march=mips64r2 -mabi=32

While it is not needed now, since the the backend support the combination now.

This patch also allows something like
     clang --target=mipsel-linux-gnu -mabi=64
Since the triple can convert to right 64bit one automaticly.

Reviewed By: MaskRay

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

[mlir][openacc][NFC] Rename ReductionOp to ReductionOperator

As we are moving on with new design for the private clause representation,
the reduction clause will aslo get remodeled. In order to new clash with
a new dedicated reduction operation, this patch rename the current
ReductionOp to ReductionOperator. It might just become obsolete once the new
design is in place.

Reviewed By: razvanlupusoru

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

[libc] Fix definition and use of LIBC_INLINE macro

LIBC_INLINE was doubly defined in two headers.  Define it only in
one place. Also update a few uses to make sure it's always placed
where a function attribute is valid and is used consistently on
every declaration of the same function in case the attributes used
in its definition must match on declarations and definitions.

Reviewed By: abrachet

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

[flang] Fix llvm-test-suite/Fortran/gfortran/torture/execute/st_function_1.f90

I just broke the test llvm-test-suite/Fortran/gfortran/torture/execute/st_function_1.f90
with a recent patch.  The bug was obvious, as is the fix, which works, so
I'm just pushing it directly to make the build bots happy.

[clang] Convert NVPTX OpenMP tests to opaque pointers

Reviewed By: nikic

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

[lld][RISCV] Handle relaxation reductions of more than 65536 bytes

In a real-world case with functions that have many, many
R_RISCV_CALL_PLT relocations due to asan and ubsan
instrumentation, all these can be relaxed by an instruction and
the net result is more than 65536 bytes of reduction in the
output .text section that totals about 1.2MiB in final size.

This changes InputSection to use a 32-bit field for bytesDropped.
The RISCV relaxation keeps track in a 64-bit field and detects
32-bit overflow as it previously detected 16-bit overflow. It
doesn't seem likely that 32-bit overflow will arise, but it's not
inconceivable and it's cheap enough to detect it.

This unfortunately increases the size of InputSection on 64-bit
hosts by a word, but that seems hard to avoid.

Reviewed By: MaskRay

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

[bazel] Fix build

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

[mlir][sparse] Add sparse rewriting rules for tensor::ReshapeOp

Reviewed By: aartbik

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

[BOLT] Fix state of MCSymbols in lowering pass

We have mostly harmless data races when running
BinaryContext::calculateEmittedSize() in parallel, while performing
split function pass.  However, it is possible to end up in a state
where some MCSymbols are still registered and our clean up
failed. This happens rarely but it does happen, and when it happens,
it is a difficult to diagnose heisenbug. To avoid this, add a new
clean pass to perform a last check on MCSymbols, before they
undergo our final emission pass, to verify that they are in a sane
state. If we fail to do this, we might resolve some symbols to zero
and crash the output binary.

Reviewed By: #bolt, Amir

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

Partially revert "Use llvm::less_second (NFC)"

This reverts part of commit e0039b8d6a5bd05e70203962f448569f2d2ef1c2.

This should fix the issue reported in:

https://github.com/llvm/llvm-project/issues/62546

[gn build] Port fcaccf817d31

[flang] Correct overriding (or not) of inaccessible bindings

Fortran doesn't allow inaccessible procedure bindings to be
overridden, and this needs to apply to generic resolution.
When resolving a type-bound generic procedure from another
module, ensure only that the most extended override from its
module is used if it is PRIVATE, not a later apparent override
from another module.

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

[libcxx] Add mdspan/extents

This patch adds std::extents. extents is one of the core classes used by std::mdspan. It describes a multi-dimensional index space with a mix of compile time and runtime sizes. Furthermore, it is templated on the index type used to describe the multi-dimensional index space.

The class is designed to be highly optimizable in performance critical code sections, and is fully useable in constant expressions contexts.

Testing of this class tends to be somewhat combinatorical, due to the large number of possible corner cases involved in situations where we have both runtime and compile time extents. To add to this, the class is designed to be interoperable (in particular constructible) from arguments which only need to be convertible to the index_type, but are otherwise arbitrary user types. For a larger discussion on the design of this class refer to: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p0009r18.html

Co-authored-by: Damien L-G <dalg24@gmail.com>
Reviewed By: ldionne, #libc

Spies: libcxx-commits, H-G-Hristov, tschuett, philnik, arichardson, Mordante, crtrott

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

hwasan: lay groundwork for importing subset of sanitizer_common interceptors [NFC]

This patch does the bare minimum to import sanitizer_common_interceptors, but
without actually enabling any interceptors or meaningfully defining the
COMMON_INTERCEPT macros.

This will allow selectively enabling sanitizer_common interceptors (if the
appropriate macros are defined), as suggested by Vitaly in D149701.

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

[libc][Obvious] Bump hermetic alloc space to 64KB.

Few hermetic tests are failing as they are running out of memory.

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

[Debuginfod] Disable llvm-debuginfod test on Windows.

[flang] Fix bogus errors about CONTIGUOUS attribute

Incorrect error messages were issuing for symbol table entries
with the CONTIGUOUS attribute that didn't deserve them, like
host association symbols.  Put the CONTIGUOUS check into
CheckObjectEntity().

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

[flang] Finer control over warnings

Establish a set of optional usage warnings, and enable some
only in "-pedantic" mode that, in our subjective experience
with application codes, seem to issue frequently without
indicating usage that really needs to be corrected.  By default,
with this patch the compiler should appear to be somewhat less
persnickety but not less informative.

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

[libc] Remove *TestMain libraries and combine them with the main test libraries.

There are not tests currently which use the main test framework but not
the `main` function from LibcTestMain.cpp. So, this change essentially
simplifies by merging the *TestMain libraries with the main test
libraries.

Reviewed By: michaelrj, jhuber6

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

Revert "[GlobalIsel][X86] Legalize G_CTPOP and G_CTLZ"

This reverts commit ef1f27d67c4ddc84f346d001af4914beb0ca6a1a.

[VPlan] Add tests to print exact and flags on calls (NFC).

Adds missing test coverage for D150029.

[clang-format] Handle <chrono> ud suffixes in IntegerLiteralSeparator

Fixes #62679.

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

[GlobalIsel][X86] Legalize G_CTPOP and G_CTLZ

G_BSWAP was reverted -> added to this diff.

check plan: ninja check-llvm-codegen-x86

Future work: G_SUB and G_ZEXT need some modernization.

Reviewed By: arsenm

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

[scudo] Deallocate the AllocatorRingBuffer too in unmapTestOnly

The AllocatorRingBuffer is allocated dynamically when Allocator is
initialized. This patch adds a corresponding deinitialization call in
unmapTestOnly, to avoid running out of virtual memory if the tests are run
a large number of times on memory-constrained platforms.

Reviewed By: Chia-hungDuan

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

[lldb][docs] Update SB API design document

The documentation should have been updated in 662548c82683.
This updates it to be more accurate with the current design.

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

[DebugInfo][NFCI] Refactor DWARFAbbreviationDeclaration::extract

The motivation behind this refactor is to be able to use
DWARFAbbreviationDeclaration from LLDB. LLDB has its own implementation
of DWARFAbbreviationDeclaration that is very similar to LLVM's but it
has different semantics around error handling.

This patch modifies llvm::DWARFAbbreviationDeclaration::extract to
return an `llvm::Expected<ExtractState>` to differentiate between "I am
done extracting" and "An error has occured", something which the current
return type (bool) does not accurately capture.

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

[RISCV] Precommit coverage for an upcoming dag combine change

ValueTracking: Expand signature of isKnownNeverInfinity/NaN

This is in preparation for replacing the implementation
with a wrapper around computeKnownFPClass.

InstCombine: Try to turn is.fpclass sign checks to fcmp with 0

Try to use gt/lt compares with 0 instead of class.

[flang] Add check for constraints on event-stmts

In the CoarrayChecker, add checks for the constraints C1177 and
C1178 for event-wait-stmt. Add event-post-stmt to the check
for the constraints for sync-stat-list. Add a check for the
constraint C1176 on event-variable.

Reviewed By: PeteSteinfeld

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

[libc++] Add C++20 stringstream::view()

Reviewed By: #libc, philnik, Mordante

Spies: Mordante, philnik, libcxx-commits

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

[gn build] Port dc95245e69a1

[libc++][format] Removes format sources.

The source file is used to anchor the destructor of format_error. When
format is moved from experimental to stable this code would move to the
dylib. One issue with code in the dylib is that it can't be used in
constexpr context. There is a proposal to make format work during
constant evaluation

  P2758 Emitting messages at compile time

This paper has initially been received favourable by EWG. Therefore move
the code to the header. This also avoids possible availability issues on
Mac back deployment targets.

Note it is expected that format will no longer be experimental with the
next LLVM release.

Reviewed By: ldionne, #libc

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

[libcxx] [test] Improve error reporting around invoked commands

This was requested in the review of D145807, but I had missed to
apply it before landing the patch.

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

[OpenMP] Compile assembly files as ASM, not C

Since CMake 3.20, CMake explicitly passes "-x c" (or equivalent)
when compiling a file which has been set as having the language
C. This behaviour change only takes place if "cmake_minimum_required"
is set to 3.20 or newer, or if the policy CMP0119 is set to new.

Attempting to compile assembly files with "-x c" fails, however
this is workarounded in many cases, as OpenMP overrides this with
"-x assembler-with-cpp", however this is only added for non-Windows
targets.

Thus, after increasing cmake_minimum_required to 3.20, this breaks
compiling the GNU assembly for Windows targets; the GNU assembly is
used for ARM and AArch64 Windows targets when building with Clang.
This patch unbreaks that.

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

Add testcase for CodeView "IsNoReturn" flag.

Reviewed in D148761; missed committing this before.

[cmake] Set CMP0091 to fix Windows builds after the cmake_minimum_required bump

The build uses other mechanism to select the runtime.

Fixes #62719

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

[libc][NFC] Simplifly inbox and outbox state handling

Currently we use a template parameter called `InvertInbox` to invert the
inbox when we load it. This is more easily understood as a static check
on whether or not the process running it is the server. Inverting the
inbox makes the states 1 0 and 0 1 own the buffer, so it's easier to
simply say that the server own the buffer if in != out. Also clean up some of
the comments.

Reviewed By: JonChesterfield

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

Emit the correct flags for the PROC CodeView Debug Symbol

The S_LPROC32_ID and S_GPROC32_ID CodeView Debug Symbols have a flags
field which LLVM has had the values for (in the ProcSymFlags enum) but
has never actually set.

These flags are used by Microsoft-internal tooling that leverages debug
information to do binary analysis.

Modified LLVM to set the correct flags:

- ProcSymFlags::HasOptimizedDebugInfo - always set, as this indicates that
debug info is present for optimized builds (if debug info is not emitted
for optimized builds, then LLVM won't emit a debug symbol at all).
- ProcSymFlags::IsNoReturn and ProcSymFlags::IsNoInline - set if the
function has the NoReturn or NoInline attributes respectively.
- ProcSymFlags::HasFP - set if the function requires a frame pointer (per
TargetFrameLowering::hasFP).

Per discussion in review, XFAIL'ing lldb test until someone working on
lldb has a chance to look at it.

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

[mlir][sparse][gpu] set cubin flag when building for cuda

Reviewed By: Peiming

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

Revert "[ASAN] Use ThreadArgRetval in ASAN"

https://bugs.chromium.org/p/chromium/issues/detail?id=1445676

This reverts commit 1030bd181eb74b67b7ea51631ce4becca410c406.

Revert "[LSAN] Use ThreadArgRetval in LSAN"

https://bugs.chromium.org/p/chromium/issues/detail?id=1445676

This reverts commit 20a3c6e84e0955ac20762c35e8c2435017ae967d.

Revert "[NFC][LSAN] Move ThreadCreate into child thread"

https://bugs.chromium.org/p/chromium/issues/detail?id=1445676

This reverts commit 6d7b26ae49b9273d9aea4e53a96901caeb09efe0.

Revert "[flang] Add check for constraints on event-stmts"

This reverts commit 9725c740fbe7841a7aed57ca35f83d28aac1814c.

[SVE ACLE] Change the lowering of SVE integer builtins

Change the lowering of SVE integer mla_x/mls_x and mad_x/msb_x
builtins to use dedicated undef (_u) intrinsics.

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

Correct documentation for -fconstexpr-depth=

We were documenting that this was about recursive calls when it's
actually about arbitrary calls.

e.g., https://godbolt.org/z/en8sYd77E

[Flang][OpenMP][Semantics] Added missing HostAssoc check for use_device_ptr test.

Missed adding this check in previous commit so adding it through separate commit.

Reviewed By: raghavendhra

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

[libc] Add optimized memcmp for RISCV

This patch adds two versions of `bcmp` optimized for architectures where unaligned accesses are either illegal or extremely slow.
It is currently enabled for RISCV 64 and RISCV 32 but it could be used for ARM 32 architectures as well.

Here is the before / after output of `libc.benchmarks.memory_functions.opt_host --benchmark_filter=BM_memcmp` on a quad core Linux starfive RISCV 64 board running at 1.5GHz.

Before
```
Run on (4 X 1500 MHz CPU s)
CPU Caches:
  L1 Instruction 32 KiB (x4)
  L1 Data 32 KiB (x4)
  L2 Unified 2048 KiB (x1)
----------------------------------------------------------------------
Benchmark            Time             CPU   Iterations UserCounters...
----------------------------------------------------------------------
BM_Memcmp/0/0        110 ns         66.4 ns     10404864 bytes_per_cycle=0.107646/s bytes_per_second=153.989M/s items_per_second=15.071M/s __llvm_libc::memcmp,memcmp Google A
BM_Memcmp/1/0        318 ns          211 ns      3026944 bytes_per_cycle=0.131539/s bytes_per_second=188.167M/s items_per_second=4.73691M/s __llvm_libc::memcmp,memcmp Google B
BM_Memcmp/2/0        204 ns          115 ns      6118400 bytes_per_cycle=0.121675/s bytes_per_second=174.058M/s items_per_second=8.70241M/s __llvm_libc::memcmp,memcmp Google D
BM_Memcmp/3/0        143 ns         99.6 ns      7013376 bytes_per_cycle=0.117974/s bytes_per_second=168.763M/s items_per_second=10.0437M/s __llvm_libc::memcmp,memcmp Google L
BM_Memcmp/4/0       81.3 ns         58.2 ns     11426816 bytes_per_cycle=0.101125/s bytes_per_second=144.661M/s items_per_second=17.1805M/s __llvm_libc::memcmp,memcmp Google M
BM_Memcmp/5/0        177 ns          118 ns      5952512 bytes_per_cycle=0.120612/s bytes_per_second=172.537M/s items_per_second=8.45549M/s __llvm_libc::memcmp,memcmp Google Q
BM_Memcmp/6/0        342 ns          220 ns      3483648 bytes_per_cycle=0.132004/s bytes_per_second=188.834M/s items_per_second=4.54739M/s __llvm_libc::memcmp,memcmp Google S
BM_Memcmp/7/0        208 ns          130 ns      5681152 bytes_per_cycle=0.12468/s bytes_per_second=178.356M/s items_per_second=7.6674M/s __llvm_libc::memcmp,memcmp Google U
BM_Memcmp/8/0        123 ns         79.1 ns      8387584 bytes_per_cycle=0.110593/s bytes_per_second=158.204M/s items_per_second=12.6439M/s __llvm_libc::memcmp,memcmp Google W
BM_Memcmp/9/0      20707 ns        10643 ns        67584 bytes_per_cycle=0.142401/s bytes_per_second=203.707M/s items_per_second=93.9559k/s __llvm_libc::memcmp,uniform 384 to 4096
```

After
```
BM_Memcmp/0/0       80.4 ns         55.8 ns     12648448 bytes_per_cycle=0.132703/s bytes_per_second=189.834M/s items_per_second=17.9256M/s __llvm_libc::memcmp,memcmp Google A
BM_Memcmp/1/0        140 ns         80.5 ns      8230912 bytes_per_cycle=0.337273/s bytes_per_second=482.474M/s items_per_second=12.4165M/s __llvm_libc::memcmp,memcmp Google B
BM_Memcmp/2/0        101 ns         66.4 ns     10571776 bytes_per_cycle=0.208539/s bytes_per_second=298.317M/s items_per_second=15.0687M/s __llvm_libc::memcmp,memcmp Google D
BM_Memcmp/3/0        118 ns         67.6 ns     10533888 bytes_per_cycle=0.176822/s bytes_per_second=252.946M/s items_per_second=14.7946M/s __llvm_libc::memcmp,memcmp Google L
BM_Memcmp/4/0        106 ns         53.0 ns     12722176 bytes_per_cycle=0.111141/s bytes_per_second=158.988M/s items_per_second=18.8591M/s __llvm_libc::memcmp,memcmp Google M
BM_Memcmp/5/0        141 ns         70.2 ns     10436608 bytes_per_cycle=0.26032/s bytes_per_second=372.39M/s items_per_second=14.2458M/s __llvm_libc::memcmp,memcmp Google Q
BM_Memcmp/6/0        144 ns         79.3 ns      8932352 bytes_per_cycle=0.353168/s bytes_per_second=505.211M/s items_per_second=12.612M/s __llvm_libc::memcmp,memcmp Google S
BM_Memcmp/7/0        123 ns         71.7 ns      9945088 bytes_per_cycle=0.22143/s bytes_per_second=316.758M/s items_per_second=13.9421M/s __llvm_libc::memcmp,memcmp Google U
BM_Memcmp/8/0       97.0 ns         56.2 ns     12509184 bytes_per_cycle=0.160526/s bytes_per_second=229.635M/s items_per_second=17.7784M/s __llvm_libc::memcmp,memcmp Google W
BM_Memcmp/9/0       1840 ns          989 ns       676864 bytes_per_cycle=1.4894/s bytes_per_second=2.08067G/s items_per_second=1010.92k/s __llvm_libc::memcmp,uniform 384 to 4096
```

glibc
```
BM_Memcmp/0/0       72.6 ns         51.7 ns     12963840 bytes_per_cycle=0.141261/s bytes_per_second=202.075M/s items_per_second=19.3246M/s glibc::memcmp,memcmp Google A
BM_Memcmp/1/0        118 ns         75.2 ns      9280512 bytes_per_cycle=0.354054/s bytes_per_second=506.478M/s items_per_second=13.3046M/s glibc::memcmp,memcmp Google B
BM_Memcmp/2/0        114 ns         62.9 ns     11152384 bytes_per_cycle=0.222675/s bytes_per_second=318.539M/s items_per_second=15.8943M/s glibc::memcmp,memcmp Google D
BM_Memcmp/3/0       84.0 ns         63.5 ns     11030528 bytes_per_cycle=0.186353/s bytes_per_second=266.581M/s items_per_second=15.7378M/s glibc::memcmp,memcmp Google L
BM_Memcmp/4/0       93.5 ns         51.2 ns     13462528 bytes_per_cycle=0.119215/s bytes_per_second=170.539M/s items_per_second=19.5384M/s glibc::memcmp,memcmp Google M
BM_Memcmp/5/0        123 ns         61.7 ns     11376640 bytes_per_cycle=0.225262/s bytes_per_second=322.239M/s items_per_second=16.1993M/s glibc::memcmp,memcmp Google Q
BM_Memcmp/6/0        122 ns         71.6 ns      9967616 bytes_per_cycle=0.380844/s bytes_per_second=544.802M/s items_per_second=13.9579M/s glibc::memcmp,memcmp Google S
BM_Memcmp/7/0        118 ns         65.6 ns     10555392 bytes_per_cycle=0.238677/s bytes_per_second=341.43M/s items_per_second=15.2334M/s glibc::memcmp,memcmp Google U
BM_Memcmp/8/0       90.4 ns         54.0 ns     12920832 bytes_per_cycle=0.161987/s bytes_per_second=231.724M/s items_per_second=18.5169M/s glibc::memcmp,memcmp Google W
BM_Memcmp/9/0       1045 ns          601 ns      1195008 bytes_per_cycle=2.53677/s bytes_per_second=3.54383G/s items_per_second=1.66423M/s glibc::memcmp,uniform 384 to 4096
```

Reviewed By: sivachandra

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

[lldb][NFCI] Small adjustment to Breakpoint::AddName

m_name_list is a std::unordered_set<std::string>, we can insert the
string directly instead of grabbing the c_str and creating yet another
one.

[AArch64] Combine add(extract v1i64) into v1i64 add

This helps fix a regression from D148309 where a shift + add was no longer
combined into a ssra. It looks for add's with v1i64 extract operands and
converts them to v1i64 adds. The other operand needs to be something that is
easily converted to a v1i64, in this case it currently just checks for a load.

Some of the code in performAddSubCombine has been cleaned up whilst I was here.

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

[flang] Parenthesize RHS arguments to defined assignments (bug #62599)

The right-hand sides of assignment statements are always expressions,
never variables.  When an assignment statement is converted into a call
to a defined assignment subroutine, and the actual argument being associated
with the second dummy argument is a variable, and the dummy argument does
not have the VALUE attribute, wrap it with parentheses so that lowering
will pass it by means of a temporary.

Fixes https://github.com/llvm/llvm-project/issues/62599.

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

[libc] Add optimized bcmp for RISCV

[libc] Add optimized bcmp for RISCV

This patch adds two versions of bcmp optimized for architectures where unaligned accesses are either illegal or extremely slow.
It is currently enabled for RISCV 64 and RISCV 32 but it could be used for ARM 32 architectures as well.

Here is the before / after output of libc.benchmarks.memory_functions.opt_host --benchmark_filter=BM_Bcmp on a quad core Linux starfive RISCV 64 board running at 1.5GHz.

Before
```
Run on (4 X 1500 MHz CPU s)
CPU Caches:
  L1 Instruction 32 KiB (x4)
  L1 Data 32 KiB (x4)
  L2 Unified 2048 KiB (x1)
Load Average: 7.03, 5.98, 3.71
----------------------------------------------------------------------
Benchmark            Time             CPU   Iterations UserCounters...
----------------------------------------------------------------------
BM_Bcmp/0/0        102 ns         60.5 ns     11662336 bytes_per_cycle=0.122696/s bytes_per_second=175.518M/s items_per_second=16.5258M/s __llvm_libc::bcmp,memcmp Google A
BM_Bcmp/1/0        328 ns          172 ns      3737600 bytes_per_cycle=0.15256/s bytes_per_second=218.238M/s items_per_second=5.80575M/s __llvm_libc::bcmp,memcmp Google B
BM_Bcmp/2/0        199 ns         99.7 ns      7019520 bytes_per_cycle=0.141897/s bytes_per_second=202.986M/s items_per_second=10.032M/s __llvm_libc::bcmp,memcmp Google D
BM_Bcmp/3/0        173 ns         86.5 ns      8361984 bytes_per_cycle=0.13863/s bytes_per_second=198.312M/s items_per_second=11.5669M/s __llvm_libc::bcmp,memcmp Google L
BM_Bcmp/4/0        105 ns         51.8 ns     13213696 bytes_per_cycle=0.116399/s bytes_per_second=166.51M/s items_per_second=19.2931M/s __llvm_libc::bcmp,memcmp Google M
BM_Bcmp/5/0        167 ns         93.9 ns      7853056 bytes_per_cycle=0.139432/s bytes_per_second=199.459M/s items_per_second=10.6503M/s __llvm_libc::bcmp,memcmp Google Q
BM_Bcmp/6/0        262 ns          165 ns      3931136 bytes_per_cycle=0.151516/s bytes_per_second=216.745M/s items_per_second=6.07091M/s __llvm_libc::bcmp,memcmp Google S
BM_Bcmp/7/0        168 ns          105 ns      6665216 bytes_per_cycle=0.143159/s bytes_per_second=204.791M/s items_per_second=9.52163M/s __llvm_libc::bcmp,memcmp Google U
BM_Bcmp/8/0        108 ns         68.0 ns     10175488 bytes_per_cycle=0.125504/s bytes_per_second=179.535M/s items_per_second=14.701M/s __llvm_libc::bcmp,memcmp Google W
BM_Bcmp/9/0      15371 ns         9007 ns        78848 bytes_per_cycle=0.166128/s bytes_per_second=237.648M/s items_per_second=111.031k/s __llvm_libc::bcmp,uniform 384 to 4096
```

After
```
BM_Bcmp/0/0       74.2 ns         49.7 ns     14306304 bytes_per_cycle=0.148927/s bytes_per_second=213.042M/s items_per_second=20.1101M/s __llvm_libc::bcmp,memcmp Google A
BM_Bcmp/1/0        108 ns         68.1 ns     10350592 bytes_per_cycle=0.411197/s bytes_per_second=588.222M/s items_per_second=14.6849M/s __llvm_libc::bcmp,memcmp Google B
BM_Bcmp/2/0       80.2 ns         56.0 ns     12386304 bytes_per_cycle=0.258588/s bytes_per_second=369.912M/s items_per_second=17.8585M/s __llvm_libc::bcmp,memcmp Google D
BM_Bcmp/3/0       92.4 ns         55.7 ns     12555264 bytes_per_cycle=0.206835/s bytes_per_second=295.88M/s items_per_second=17.943M/s __llvm_libc::bcmp,memcmp Google L
BM_Bcmp/4/0       79.3 ns         46.8 ns     14288896 bytes_per_cycle=0.125872/s bytes_per_second=180.061M/s items_per_second=21.3611M/s __llvm_libc::bcmp,memcmp Google M
BM_Bcmp/5/0       98.0 ns         57.9 ns     12232704 bytes_per_cycle=0.268815/s bytes_per_second=384.543M/s items_per_second=17.2711M/s __llvm_libc::bcmp,memcmp Google Q
BM_Bcmp/6/0        132 ns         65.5 ns     10474496 bytes_per_cycle=0.417246/s bytes_per_second=596.875M/s items_per_second=15.2673M/s __llvm_libc::bcmp,memcmp Google S
BM_Bcmp/7/0        101 ns         60.9 ns     11505664 bytes_per_cycle=0.253733/s bytes_per_second=362.968M/s items_per_second=16.4202M/s __llvm_libc::bcmp,memcmp Google U
BM_Bcmp/8/0       72.5 ns         50.2 ns     14082048 bytes_per_cycle=0.183262/s bytes_per_second=262.158M/s items_per_second=19.9271M/s __llvm_libc::bcmp,memcmp Google W
BM_Bcmp/9/0        852 ns          803 ns       854016 bytes_per_cycle=1.85028/s bytes_per_second=2.58481G/s items_per_second=1.24597M/s __llvm_libc::bcmp,uniform 384 to 4096
```

For comparison with glibc
```
BM_Bcmp/0/0        106 ns         52.6 ns     12906496 bytes_per_cycle=0.142072/s bytes_per_second=203.235M/s items_per_second=19.0271M/s glibc::bcmp,memcmp Google A
BM_Bcmp/1/0        132 ns         77.1 ns      8905728 bytes_per_cycle=0.365072/s bytes_per_second=522.239M/s items_per_second=12.9782M/s glibc::bcmp,memcmp Google B
BM_Bcmp/2/0        122 ns         62.3 ns     10909696 bytes_per_cycle=0.222667/s bytes_per_second=318.527M/s items_per_second=16.0563M/s glibc::bcmp,memcmp Google D
BM_Bcmp/3/0       99.5 ns         64.2 ns     11074560 bytes_per_cycle=0.185126/s bytes_per_second=264.825M/s items_per_second=15.5674M/s glibc::bcmp,memcmp Google L
BM_Bcmp/4/0       86.6 ns         50.2 ns     13488128 bytes_per_cycle=0.117941/s bytes_per_second=168.717M/s items_per_second=19.9053M/s glibc::bcmp,memcmp Google M
BM_Bcmp/5/0        106 ns         61.4 ns     11344896 bytes_per_cycle=0.248968/s bytes_per_second=356.151M/s items_per_second=16.284M/s glibc::bcmp,memcmp Google Q
BM_Bcmp/6/0        145 ns         71.9 ns     10046464 bytes_per_cycle=0.389814/s bytes_per_second=557.633M/s items_per_second=13.9019M/s glibc::bcmp,memcmp Google S
BM_Bcmp/7/0        119 ns         65.6 ns     10718208 bytes_per_cycle=0.243756/s bytes_per_second=348.696M/s items_per_second=15.2329M/s glibc::bcmp,memcmp Google U
BM_Bcmp/8/0       86.4 ns         54.5 ns     13250560 bytes_per_cycle=0.154831/s bytes_per_second=221.488M/s items_per_second=18.3532M/s glibc::bcmp,memcmp Google W
BM_Bcmp/9/0       1090 ns          604 ns      1186816 bytes_per_cycle=2.53848/s bytes_per_second=3.54622G/s items_per_second=1.65598M/s glibc::bcmp,uniform 384 to 4096
```

Reviewed By: sivachandra

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

[DWARFLinker][DWARFv5] Add handling of DW_OP_addrx and DW_OP_constx expression operands.

This patch adds handling of DW_OP_addrx and DW_OP_constx expression operands.
In --update case these operands are preserved as is. Otherwise they are
converted into the DW_OP_addr and DW_OP_const[*]u correspondingly.

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

[clang] Convert a few OpenMP tests to opaque pointers

Reviewed By: nikic

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

[clang] Convert a few OpenMP tests to opaque pointers

Reviewed By: nikic

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

[mlir][sparse] Add a helper class to help lowering operations with/without function calls

Reviewed By: aartbik

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

[flang] Apply default module accessibility rules a second time (bug#62598)

Apply the default PUBLIC/PRIVATE accessibility of a module to its symbols
a second time after it is known that all symbols, including implicitly typed
names from NAMELIST groups and specification expressions in module subprograms,
have been created in its scope.

Fixes https://github.com/llvm/llvm-project/issues/62598.

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

Migrate {starts,ends}with_insensitive to {starts,ends}_with_insensitive (NFC)

This patch migrates uses of StringRef::{starts,ends}with_insensitive
to StringRef::{starts,ends}_with_insensitive so that we can use names
similar to those used in std::string_view.

Note that the llvm/ directory has migrated in commit
6c3ea866e93003e16fc55d3b5cedd3bc371d1fde.

I'll post a separate patch to deprecate
StringRef::{starts,ends}with_insensitive.

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

[Hexagon] Fix HVX predicates on some intrinsic selection patterns

Instead of checking arch version, check HVX version when dealing with
HVX instructions.

[clangd][check] Print directory with compile flags

[flang] Don't mistakenly tokenize a Hollerith literal from "DO 100 H=..." (bug #58732)

After tokenizing an identifier, don't allow the next token to be a
Hollerith literal.

Fixes https://github.com/llvm/llvm-project/issues/58732.

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

[Clang][Flang][OpenMP] Add loadOffloadInfoMetadata and createOffloadEntriesAndInfoMetadata into OMPIRBuilder's finalize and initialize

This allows the generation of OpenMP offload metadata for the OpenMP
dialect when lowering to LLVM-IR and moves some of the shared logic
between the OpenMP Dialect and Clang into the IRBuilder.

Reviewers: jsjodin, jdoerfert, kiranchandramohan

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

[flang] Fixed comparison for derived types constants.

The two constants should be equal only if their derived types
are the same. This fixes regression caused by D150380.

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

[clangd] Fix test.

[RISCV] Rework how implied SP operands work in the disassembler. NFC

Previously we added the SP operands when an immediate operand was added
to certain opcodes.

This patch moves it to a post processing step using the information
in MCInstrDesc. This avoids an explicit opcode list in RISCVDisassembler.cpp.

In considered using a custom DecoderMethod, but the bit swizzling we
need to do for the immediates on these instructions made that
unattractive.

Reviewed By: asb

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

[bazel] Fix build after 0c4d7d14e94d

[lldb] Define lldbassert based on NDEBUG instead of LLDB_CONFIGURATION_DEBUG

Whether assertions are enabled or not is orthogonal to the build type
which could lead to surprising behavior for lldbassert. Previously, when
doing a debug build with assertions disabled, lldbassert would become a
NOOP, rather than printing an error like it does in a release build. By
definining lldbassert in terms of NDEBUG, it behaves like a regular
assert when assertions are enabled, and like a soft assert.

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

[llvm-objdump][X86] Add @plt symbols for .plt.got

If a symbol needs both JUMP_SLOT and GLOB_DAT relocations, there is a
minor linker optimization to keep just GLOB_DAT. This optimization
is only implemented by GNU ld's x86 port and mold.
https://maskray.me/blog/2021-08-29-all-about-global-offset-table#combining-.got-and-.got.plt

With the optimizing, the PLT entry is placed in .plt.got and the
associated GOTPLT entry is placed in .got (ld.bfd -z now) or .got.plt (ld.bfd -z lazy).
The relocation is in .rel[a].dyn.

This patch synthesizes `symbol@plt` labels for these .plt.got entries.

Example:
```
cat > a.s <<e
.globl _start; _start:
mov combined0@gotpcrel(%rip), %rax; mov combined1@gotpcrel(%rip), %rax
call combined0@plt; call combined1@plt
call foo0@plt; call foo1@plt
e
cat > b.s <<e
.globl foo0, foo1, combined0, combined1
foo0: foo1: combined0: combined1:
e
gcc -fuse-ld=bfd -shared b.s -o b.so
gcc -fuse-ld=bfd -pie -nostdlib a.s b.so -o a
```

```
Disassembly of section .plt:

0000000000001000 <.plt>:
    1000: ff 35 ea 1f 00 00             pushq   0x1fea(%rip)            # 0x2ff0 <_GLOBAL_OFFSET_TABLE_+0x8>
    1006: ff 25 ec 1f 00 00             jmpq    *0x1fec(%rip)           # 0x2ff8 <_GLOBAL_OFFSET_TABLE_+0x10>
    100c: 0f 1f 40 00                   nopl    (%rax)

0000000000001010 <foo1@plt>:
    1010: ff 25 ea 1f 00 00             jmpq    *0x1fea(%rip)           # 0x3000 <_GLOBAL_OFFSET_TABLE_+0x18>
    1016: 68 00 00 00 00                pushq   $0x0
    101b: e9 e0 ff ff ff                jmp     0x1000 <.plt>

0000000000001020 <foo0@plt>:
    1020: ff 25 e2 1f 00 00             jmpq    *0x1fe2(%rip)           # 0x3008 <_GLOBAL_OFFSET_TABLE_+0x20>
    1026: 68 01 00 00 00                pushq   $0x1
    102b: e9 d0 ff ff ff                jmp     0x1000 <.plt>

Disassembly of section .plt.got:

0000000000001030 <combined0@plt>:
    1030: ff 25 a2 1f 00 00             jmpq    *0x1fa2(%rip)           # 0x2fd8 <foo1+0x2fd8>
    1036: 66 90                         nop

0000000000001038 <combined1@plt>:
    1038: ff 25 a2 1f 00 00             jmpq    *0x1fa2(%rip)           # 0x2fe0 <foo1+0x2fe0>
    103e: 66 90                         nop
```

For x86-32, with -z now, if we remove `foo0` and `foo1`, the absence of regular
PLT will cause GNU ld to omit .got.plt, and our code cannot synthesize @plt
labels. This is an extreme corner case that almost never happens in practice (to
trigger the case, ensure every PLT symbol has been taken address). To fix it, we
can get the `_GLOBAL_OFFSET_TABLE_` symbol value, but the complexity is not
worth it.

Close https://github.com/llvm/llvm-project/issues/62537

Reviewed By: bd1976llvm

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

[AArch64] Use correct IRBuilder in InstCombine hooks

These need to use the IRBuilder provided by InstCombine for proper
worklist management.

Add doc link to missing include diagnostics.

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

[clang] Convert a couple of OpenMP tests to opaque pointers

This is a follow-up to D150608.

Revert "[libc] Add explicit constructor calls to fix compilation when using UInt<T>"

This reverts commit b663993067ffb5800632ad41ea7f2f92caab1093.

This caused a regression on aarch64:
https://lab.llvm.org/buildbot#builders/138/builds/43983

[libc] Add explicit constructor calls to fix compilation when using UInt<T>

This patch is similar to 86fe88c8d9 and adds several explicit
constructor calls (bool(...), uint64_t(...), uint8_t(...)) that are
needed when we use UInt<T> (in my case UInt<128> in riscv32).

This patch also adds two operators to UInt<T>:
* operator/= required by printf_core/float_hex_converter.h:148
* operator-- required by FPUtil/ManipulationFunctions.h:166

Reviewed By: sivachandra, lntue

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

[mlir][Linalg] Split vectorization tests

Split Linalg vectorization tests from "vectorization.mlir" across more
specialised test files:
  * vectorize-tensor-extract.mlir - tests for tensor.extract with no
    masking,
  * vectorize-tensor-extract-masked.mlir - tests for tensor.extract with
    masking,
  * vectorization-masked.mlir - all other tests that use masking,
  * vectorisation.mlir - the remaining tests.

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

[Driver] Support multi /guard: options

Reviewed By: rnk

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

[mlir][openacc] Add ReturnLike trait to acc.yield operation

Just add the trait as acc.yield is a return like op.

Reviewed By: razvanlupusoru, jeanPerier

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

[AMDGPU][InferAddressSpaces] Only rewrite address-spaces that can be trivially casted to flat for llvm.amdgcn.flat.atomic.{fadd,fmax,fmin}

The intrinsic @llvm.amdgcn.flat.atomic.{fadd,fmax,fmin} can only be
selected for flat address spaces (constant, flat and global).

This patch restricts the cases over which GCNTTIImpl::rewriteIntrinsicWithAddressSpace
rewrites the intrinsic.

Reviewed By: arsenm

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

LangRef: Clarify behavior of minnum/maxnum

Make it clearer minnum(+0, +0) cannot return -0. Also remove
a note about the result always being quiet which is directly
contradicted by the following paragraph.