[flang][hlfir] Implement the scheduling part of hlfir.forall codegen

The lowering of hlfir.forall to loops (and later hlfir.where) requires
doing a data dependency analysis to avoid creating temporary storage for
every control/mask/rhs/lhs expressions.

The added code implements a data dependency analysis for the hlfir
ordered assignment trees (it is not specific to Forall since these nodes
includes Where, user defined assignments, and assignment to vector
subscripted entities, but the added code is only plugged and tested
with hlfir.forall in this patch).

This data dependency analysis returns a "schedule", which is a list of
runs containing actions. Each runs will result in a single loop nest
evaluating all its action "at the same time" inside the loop body.
Actions may either evaluating an assignment, or saving some expression
evaluation (the value yielded inside the ordered assignment hlfir operations)
in a temporary storage before doing the assignment that requires this
expression value but may "conflict" with it.

A "conflict" is a read in an expression E to a variable that is, or may
be (analysis is conservative), written by an assignment that depends on
E.

The analysis is based on MLIR SideEffectInterface and fir AliasAnalysis
which makes it generic.

For now, the codegen that will apply the schedule and rewrite the
hlfir.forall into a set of loops is not implemented, but the scheduling
is tested on its own (from Fortran, because it allows testing many cases
in very readable fashions).

The current scheduling has limitations, for instance
"forall(i=1, 10) x(i)=2*x(i)" does not require saving the RHS values for
all "i" before doing the assignments since the RHS does not depend
on values computed during previous iterations. Any user call will also
trigger a conservative assumption that there is a conflict. Finally,
a lot of operations are missing memory effect interfaces (especially
in HLFIR). This patch adds a few so that it can be tested, but more
will be added in later patches.

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

[SLP] Rename IsUniformStride to IsUnitStride. NFCI

IsUniformStride is only used when the stride is a unit-stride, i.e. in a
plain wide vector load. This tightens the condition and renames it to
isUnitStride. It removes the old unused getUniformStrided() variant, as
isUnitStride should now imply that the stride is known.

Reviewed By: vdmitrie, ABataev

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

[bazel] Fix missing deps for layering check

Dependency was introduced by
https://github.com/llvm/llvm-project/commit/2c874d2128e35bb38817f349cfdfe9eca7281c9d

[JITLink][RISCV] Disable some relaxation tests on no-asserts builds

Some tests used `-debug-only` which only exists on builds with asserts
enabled.

[lldb][gnustep] Add minimal GNUstepObjCRuntime plugin for LanguageTypeObjC on non-Apple platforms

This is the next patch after D146058. We can now parse expressions to print instance variables from ObjC classes. Until now the expression parser would bail out with an error like this:
```
error: expression failed to parse:
error: Error [IRForTarget]: Couldn't find Objective-C indirect ivar symbol OBJC_IVAR_$_TestObj._int
```

Reviewed By: aprantl

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

[X86] Remove patterns for shift/rotate with immediate 1 and optimize during MC lowering

It's first suggested by @craig.topper  in D150068. I think there are at least three pros

1. This can reduce the patterns during ISEL, as a result, reducing the bytes in X86GenDAGISel.inc
2. The patterns for shift/rotate with immediate 1 look quite similar to shift/rotate with immediate 8. So this can be seen as eliminating "duplicate" code.
3. Delay the optimization from imm8 to imm1, so that the previous optimization passes do not need to handle the version of imm1

It improves fast isel code and makes X86DomainReassignment work for shifts by 1, but regressed global isel, though no one should care.

Reviewed By: craig.topper

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

[Hexagon] Improve safety of aligned loads/stores in HVC

Generate a predicated variant of the last load/store in a group to
avoid accessing OOB memory. Disable vector alignment on HVX prior
to v62, since v62 does not have predicated vector loads.

Fix MSVC "result of 32-bit shift implicitly converted to 64 bits" warning. NFC.

[mlir][llvm] Mark additional ops as pure.

The revision marks the overflow arithmetic intrinsics
and the freeze operation as pure. This change enables
inlining and possible other optimizations for these
operations.

Reviewed By: Dinistro

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

[AMDGPU] Regenerate test checks after D149986

[RISCV][NFC] Remove LMUL from vmv.s.x and vmv.x.s scheduler classes

These instructions don't read or write register groups. We only pretend they do in intrinsics and pseudoinstructions.

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

[Lex] Warn when defining or undefining any builtin macro

Currently we warn when MI->isBuiltinMacro, but this is only true for
builtin macros that require processing when expanding. Checking
SourceMgr.isWrittenInBuiltinFile in addition to this will mean that
we catch all builtin macros, though we shouldn't warn on feature test
macros.

As part of doing this I've also moved the handling of undefining from
CheckMacroName to HandleUndefDirective, as it doesn't really make
sense to handle undefining in CheckMacroName but defining in
HandleDefineDirective. It would be nice to instead handle both in
CheckMacroName, but that isn't possible as the handling of defines
requires looking at what the name is being defined to.

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

[Instsimplfy] X == Y ? 0 : X ^ Y --> X ^ Y

Alive2: https://alive2.llvm.org/ce/z/cykffE
Fixes: https://github.com/llvm/llvm-project/issues/62753

Reviewed By: nikic
Differential Revision: https://reviews.llvm.org/D150750

[ValueTracking] Fix i1 abs range (PR62760)

For i1 operations, we may end up returning an empty range instead
of a full one. Make sure to use the getNonEmpty constructor.

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

[InstSimplify] Add tests for PR62760 (NFC)

Revert "[Driver][gcov] Derive .gcno .gcda file names from -o and -dumpdir"

This reverts commit d515b8125364ef85fb100f1430b2174ed816cc18.

Caused buildbot failures:
  https://lab.llvm.org/buildbot/#/builders/197/builds/5464

Please fix before recommitting.

[Support] Forward GenCrashDiag argument from report_fatal_error(Error, bool)

The boolean GenCrashDiag argument was previous just discarded, which
seems to be an oversight that existed when this overload was first
added.

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

[C++20] [Modules] Emit a warning if the we load the modules by implicit generated path

A step to address https://github.com/llvm/llvm-project/issues/62707.

It is not user friendly enough to drop the implicitly generated path
directly. Let's emit the warning first and drop it in the next version.

[RISCV][MC] Refine MCInstrAnalysis based on registers used

MCInstrAnalysis provides a number of methods to query properties of
instructions (e.g., isTerminator(), isCall(),...). The default
implementation of these methods forwards the query to MCInstrDesc which
returns information based on various RISCVInstrInfo*.td files.

Since the info in MCInstrDesc is based on opcodes only, it is often
quite inaccurate. For example, JAL/JALR are never recognized as
terminators or branches while they certainly can be. However,
MCInstrAnalysis has access to the full MCInst so can improve accuracy by
inspecting registers used by the instruction.

This patch refines the following MCInstrAnalysis methods:
- isTerminator: JAL/JALR with RD=X0;
- isCall: JAL/JALR with RD!=X0
- isReturn: JALR/C_JR with RD=X0, RS1 in {X1, X5}
- isBranch: JAL/JALR/C_JR with RD=X0, RS1 not in {X1, X5};
- isUnconditionalBranch: JAL/JALR/C_JR with RD=X0, RS1 not in {X1, X5};
- isIndirectBranch: JALR/C_JR with RD=X0, RS1 not in {X1, X5};

Note that the reason for this patch is to simplify the RISCV target in
BOLT. While it's possible to implement everything there, it seems more
logical to implement it directly in the RISCV backend as other tools
might also be able to benefit from it.

Reviewed By: craig.topper, MaskRay

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

[RISCV] Allow LI with symbol difference as constant

This patch lets the assembler accept code like the following:

.Lbuf: ...
.set .Lbuf_len, . - .Lbuf
li a0, .Lbuf_len

It works by translating such instances of LI into an ADDI and inserting
the correct constant value via a new fixup.

Note that this means that the constant value is restricted to 12 bits
since we cannot insert new instructions during the relaxation stage.
Binutils seems to have the same restriction though.

This patch also fixes a small issue where the SMLoc of an LI wasn't
propagated when translated to ADDI. While this is technically unrelated
to the main functionality of this patch, it improves error messages
related to the new use of LI.

This patch does _not_ allow I-type instructions to take such symbolic
constants as well. While technically possible (and allowed by binutils),
it's probably better to implement this in another patch.

Fixes #57461

Reviewed By: asb

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

[JITLink][RISCV] Implement linker relaxation

This patch is essentially an adaption of LLD's algorithm to JITLink.
Currently, only relaxing R_RISCV_CALL(_PLT) and R_RISCV_ALIGN is
implemented, other relocations can follow later.

From a high level, the algorithm works as follows. In the first phase
(relaxBlock), we iteratively try to relax all instructions that have a
R_RISCV_RELAX relocation:
- If, based on the current symbol values, an instruction sequence can be
  relaxed (i.e., replaced by a shorter instruction), we record how many
  bytes would be removed, the new instruction (Writes), and the new
  relocation type (EdgeKinds).
- We keep track of the total number of bytes that got removed up to each
  relocation in the RelocDeltas array. This is the cumulative sum of the
  number of bytes removed for each relocation.
- Symbol values and sizes are updated based on the number of removed
  bytes.
- If for any relocation, the current RelocDeltas value doesn't match the
  one from the previous iteration, something changed and we need to run
  another iteration as some symbols might now have different values.

In the second phase (finalizeBlockRelax), all code is moved based on
RelocDeltas, the relaxed instructions are rewritten using Writes, and
R_RISCV_ALIGN is handled (moving instructions to ensure alignment and
inserting the correct NOP-sequence if needed). Finally, edge kinds and
offsets are updated and all R_RISCV_RELAX and R_RISCV_ALIGN edges are
removed (they are not needed anymore for the fixup linking stage).

Linker relaxation is implemented as a pass and added to PreFixupPasses
in the default configuration on RISC-V.

Since linker relaxation removes instructions, the memory for blocks
should ideally be reallocated. However, I believe this is currently not
possible in JITLink. Therefore, relaxation directly modifies the memory
of blocks, reducing the number of instructions but not the size of
blocks. I'm not very familiar with JITLink's memory allocators so I
might be overlooking something here, though.

Note on testing: some of the tests rely on the debug output of
llvm-jitlink. The main reason for this is the verification of symbol
sizes (which may change due to relaxation). I don't believe this can be
done using jitlink-check checks alone.

Note that there is a slightly unrelated change that makes
Symbol::setOffset public to be able to update symbol offsets during
relaxation.

Reviewed By: lhames

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

[JITLink] Add target features to LinkGraph

This patch adds SubtargetFeatures to LinkGraph. Similar to Triple, some
targets might use this information while linking.

One example, and the reason this patch was written, is linker relaxation
on RISC-V: different relaxations are possible depending on if the C
extension is enabled.

Note that the features are stored as `std::vector<std::string>` to prevent a
public dependency on MC. There is still a private dependency to be able to
convert SubtargetFeatures to a vector.

Reviewed By: lhames

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

[clang][dataflow] Add `Strict` versions of `Value` and `StorageLocation` accessors.

This is part of the gradual migration to strict handling of value categories, as described in the RFC at https://discourse.llvm.org/t/70086.

This patch migrates some representative calls of the newly deprecated accessors to the new `Strict` functions. Followup patches will migrate the remaining callers.  (There are a large number of callers, with some subtlety involved in some of them, so it makes sense to split this up into multiple patches rather than migrating all callers in one go.)

The `Strict` accessors as implemented here have some differences in semantics compared to the semantics originally proposed in the RFC; specifically:

*  `setStorageLocationStrict()`: The RFC proposes to create an intermediate
   `ReferenceValue` that then refers to the `StorageLocation` for the glvalue.
   It turns out though that, even today, most places in the code are not doing
   this but are instead associating glvalues directly with their
   `StorageLocation`. It therefore didn't seem to make sense to introduce new
   `ReferenceValue`s where there were none previously, so I have chosen to
   instead make `setStorageLocationStrict()` simply call through to
   `setStorageLocation(const Expr &, StorageLocation &)` and merely add the
   assertion that the expression must be a glvalue.

*  `getStorageLocationStrict()`: The RFC proposes that this should assert that
   the storage location for the glvalue expression is associated with an
   intermediate `ReferenceValue`, but, as explained, this is often not true.
   The current state is inconsistent: Sometimes the intermediate
   `ReferenceValue` is there, sometimes it isn't. For this reason,
   `getStorageLocationStrict()` skips past a `ReferenceValue` if it is there but
   otherwise directly returns the storage location associated with the
   expression. This behavior is equivalent to the existing behavior of
   `SkipPast::Reference`.

*  `setValueStrict()`: The RFC proposes that this should always create the same
   `StorageLocation` for a given `Value`, but, in fact, the transfer functions
   that exist today don't guarantee this; almost all transfer functions
   unconditionally create a new `StorageLocation` when associating an expression
   with a `Value`.

   There appears to be one special case:
   `TerminatorVisitor::extendFlowCondition()` checks whether the expression is
   already associated with a `StorageLocation` and, if so, reuses the existing
   `StorageLocation` instead of creating a new one.

   For this reason, `setValueStrict()` implements this logic (preserve an
   existing `StorageLocation`) but makes no attempt to always associate the same
   `StorageLocation` with a given `Value`, as nothing in the framework appers to
   require this.

   As `TerminatorVisitor::extendFlowCondition()` is an interesting special case,
   the `setValue()` call there is among the ones that this patch migrates to
   `setValueStrict()`.

Reviewed By: sammccall, ymandel, xazax.hun

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

[bazel] Fix missing dependencies for OpenMP

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

Fix test bot breakage from bd0dd27bb5be0fbf60c1b2a4ce15188812388574

This addresses the issue found by: https://lab.llvm.org/buildbot/#/builders/93/builds/14929

[NFC] Update .git-blame-ignore-revs with python reformatting

[NFC][Py Reformat] Reformat python files in llvm

This is the first commit in a series that will reformat
all the python files in the LLVM repository.

Reformatting is done with `black`.

See more information here:

https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style

Reviewed By: jhenderson, JDevlieghere, MatzeB

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

[AArch64][NFC] Refactor the tail-folding option

This patch does simple refactoring of the tail-folding
option in preparation for enabling tail-folding by
default for neoverse-v1. It adds a default tail-folding
option field to the AArch64Subtarget class that can
be set on a per-CPU.

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

[lldb][gnustep] Add basic test and infrastructure for GNUstep ObjC runtime

This patch adds test infrastructure to utilize the GNUstep runtime in the LLDB test suite and adds coverage for features that already work on Linux. These seem accidental in parts, but it's a good early baseline. On Windows nothing works yet. Please find the repository for the GNUstep ObjC runtime here: https://github.com/gnustep/libobjc2

GNUstep support is disabled by default. CMake configuration involves two variables:
* `LLDB_TEST_OBJC_GNUSTEP=On` enables GNUstep support in the test suite. It requires the libobjc2 shared library and headers to be found.
* `LLDB_TEST_OBJC_GNUSTEP=Off` disables GNUstep support in the test suite and resets associated cache values if necessary (default).
* `LLDB_TEST_OBJC_GNUSTEP_DIR` allows to pass a custom installation root.

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

tsan: fix string comparison in Go build script

Some bots failed with:

buildgo.sh: 173: [: linux: unexpected operator
Unknown platform

https://lab.llvm.org/buildbot/#/builders/247/builds/4603

Reviewed By: dyung

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

[cmake] Correct option to LLVM_FORCE_USE_OLD_TOOLCHAIN

This option was renamed a long time ago in commit 388cefa78d.

[ClangTidy] Fix markup in comments

[clang][Interp][NFC] Move dyn_cast check into if condition

M is not used anywhere else.

[libc++][ranges] Implement the changes to `deque` from P1206 (`ranges::to`):

- add the `from_range_t` constructors and the related deduction guides;
- add the `insert_range`/`assign_range`/etc. member functions.

(Note: this patch is split from https://reviews.llvm.org/D142335)

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

[Driver][gcov] Derive .gcno .gcda file names from -o and -dumpdir

Resolve a FIXME.
When -ftest-profile, -fprofile-arcs, or --coverage is specified and the
driver performs both compilation and linking phases, derive the .gcno &
.gcda file names from -o and -dumpdir.

`clang --coverage d/a.c d/b.c -o e/x && e/x` will now emit
`e/x-[ab].gc{no,da}` like GCC.

For -fprofile-dir=, we make the deliberate decision to not mangle the
input filename if relative.

The following script demonstrates the .gcno and .gcda filenames.

```
PATH=/tmp/Rel/bin:$PATH                # adapt according to your build directory
mkdir -p d e f
echo 'int main() {}' > d/a.c
echo > d/b.c

a() { rm $@ || exit 1; }

clang --coverage d/a.c d/b.c && ./a.out
a a-[ab].gc{no,da}
clang --coverage d/a.c d/b.c -o e/x && e/x
a e/x-[ab].gc{no,da}
clang --coverage d/a.c d/b.c -o e/x -dumpdir f/ && e/x
a f/[ab].gc{no,da}
clang --coverage -fprofile-dir=f d/a.c d/b.c -o e/x && e/x
a e/x-[ab].gcno f/e/x-[ab].gcda

clang -c --coverage d/a.c d/b.c && clang --coverage a.o b.o && ./a.out
a [ab].gc{no,da}
clang -c --coverage -fprofile-dir=f d/a.c d/b.c && clang --coverage a.o b.o && ./a.out
a [ab].gcno f/[ab].gcda

clang -c --coverage d/a.c -o e/xa.o && clang --coverage e/xa.o && ./a.out
a e/xa.gc{no,da}
clang -c --coverage d/a.c -o e/xa.o -dumpdir f/g && clang --coverage e/xa.o && ./a.out
a f/ga.gc{no,da}
```

The gcov code accidentally claims -c and -S, so -fsyntax-only -c/-S and
-E -c/-S don't leave to a -Wunused-command-line-argument warning. Keep
the unintended code for now.

Revert "[GVN] Improve PRE on load instructions"

This reverts commit d6811826371d82de074d0c3e10040114eee69897.

It caused sanitized bootstrap failure.

[clang][analyzer] Display buffer sizes in StdCLibraryFunctionArgs checker

If a wrong (too small) buffer argument is found, the dynamic buffer size and
values of connected arguments are displayed in the warning message, if
these are simple known integer values.

Reviewed By: Szelethus

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

tsan: allow to cross-build Go runtime

Allow user to provide target GOOS/GOARCH.
If not provided, use the host GOOS/GOARCH as we do now.
This allows to cross-compile the runtime.
Also provide SKIP_TEST knob for cross-compilation
since the test will most likely not run on host.

Reviewed By: vitalybuka

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

[AMDGPU] Add missing whitespace in SIInstrInfo header (NFC)

[AMDGPU][UniformityAnalysis] Fix typos in test comment (NFC)

[X86] Combine constant vector inputs for FMA

Inspired by https://discourse.llvm.org/t/folding-memory-into-fma/69217

Reviewed By: pengfei

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

[X86] Add a fneg test for fma with a splat constant vector

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

[Driver][test] fix cuda-simple.cu: -fsyntax-only -c => -c

[Driver][test] fix cuda-simple.cu: -fsyntax-only -c => -c

-fsyntax -c is supposed to lead to a -Wunused-command-line-argument
warning. There is currently no due to a gcov FIXME in
addPGOAndCoverageFlags.

[InstCombine] Update instcombine for vectorOps to use new shufflevector semantics

This patch updates the transformations in InstCombineVectorOps to use the new
hufflevector semantics that say that undefined values in the mask yield poison.

To prevent miscompilations we have to match with m_Poison instead of m_Undef.
Otherwise, we might introduce poison where there was previously undef.

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

[mlir][llvm] Saturation arithmetic intrinsics.

Add the saturation arithmetic intrinsics to the LLVM dialect.

Reviewed By: Dinistro

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

[gn build] Port 544e38ca439f

[libc++] Utilities for implementing stop_token

This change contains three util classes that were out from D145183 to make incremental progress
- automic_unique_lock
- intrusive_list
- intrusive_shared_ptr

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

hwasan: fix buildbot breakage (unused functions)

This addresses another buildbot breakage:
https://lab.llvm.org/buildbot/#/builders/37/builds/22166

My patch, https://reviews.llvm.org/D150708 introduced
stubs for common interceptor macros; these had unused
variables and functions. An earlier patch fixed the
unused variables; this patch suppresses unused-functions
warnings.

[hwasan] Fix build breakage (-Wunused-function) in hwasan_interceptors.cpp (NFC)

In file included from /data/llvm-project/compiler-rt/lib/hwasan/hwasan_interceptors.cpp:141:
/data/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common_interceptors.inc:1044:13: error: unused function 'write_iovec' [-Werror,-Wunused-function]
static void write_iovec(void *ctx, struct __sanitizer_iovec *iovec,
            ^
/data/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common_interceptors.inc:1053:13: error: unused function 'read_iovec' [-Werror,-Wunused-function]
static void read_iovec(void *ctx, struct __sanitizer_iovec *iovec,
            ^
/data/llvm-project/compiler-rt/lib/hwasan/../sanitizer_common/sanitizer_common_interceptors.inc:10363:13: error: unused function 'InitializeCommonInterceptors' [-Werror,-Wunused-function]
static void InitializeCommonInterceptors() {
            ^
3 errors generated.

[FS-AFDO] Clean up non-zero discriminator for pseudo probes at the first FS discriminator pass.

The dwarf discriminator field for pseudo probes is not supposed to be used until the first FS discriminator pass. Unfortunately there are always corner cases that accidientally set this field. For example, the inliner could set this field for an inlined instruction if the instruction does not come with any debug information. While fixing all such spots is possible, but for future-proff I'd like to enforce a general cleanup before assigning probes any FS discriminator.

Reviewed By: wenlei

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

[PseudoProbe] Only emit discriminstor in FS-AFDO mode.

Despite previous effort {D148569} to avoid screwing up existing disrminator field, I'm still seeing some call probes getting a non-zero discriminator eventually in non-FS mode. It could be related to callsite merge. While they are investigated I'm disabling discriminator emission for non-FS mode. This avoids breaking the compatiblity with older tools like llvm-profgen and bolt.

Reviewed By: wenlei

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

[SCEV][NFC-mostly] Remove constant handling in TripMultiple computation

After landing more precise trip multiples in
https://reviews.llvm.org/D149529, the SCEV multiple computation handles
constants, so there is no longer any need for special constant handling
in getSmallConstantTripMultiple.

This patch can improve the multiple of a non-constant SCEV that is huge
(>=2**32). This is very rare in practice.

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

hwasan: fix buildbot breakage (unused variables)

This (hopefully) fixes the buildbot breakage:
https://lab.llvm.org/buildbot/#/builders/77/builds/26793

My patch, https://reviews.llvm.org/D150708 introduced
stubs for common interceptor macros; these had unused
variables. This patch suppresses unused-variable
warnings.

[X86]check that Uses, Defs are same for entries in memory folding table

Add expensive check that Uses, Defs are same for entries in memory folding table.
MemFolding could not change the Uses/Defs.

Reviewed By: skan

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

[Uniformity] Propagate divergence only along divergent outputs.

When an instruction is determined to be divergent, not all its outputs are
divergent. The users of only divergent outputs should now be examined for
divergence.

Also, replaced a repeating pattern of "if new divergent instruction, then add to
worklist" by combining it into a single function. This does not cause any change
in functionality.

Reviewed By: foad, arsenm

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

[ARM] Remove unused declaration isSafeToDefineLR

The corresponding function definition was removed by:

  commit e82a0084d322948b94a5ca3213237d5eeab4920f
  Author: Sam Parker <sam.parker@arm.com>
  Date:   Fri Sep 25 09:36:40 2020 +0100

[ConstantFolding] fold integer bitwidth is greater than 63, and not multiple of 8 variables
Differential Revision: https://reviews.llvm.org/D150422

[ARM] Remove unused declaration ARMBaseRegisterInfoARMBaseRegisterInfo::getOpcode

[Hexagon] Remove getFirstCallerSavedNonParamReg

The last use was removed by:

  commit 9eb75c45204781886c8d598a1bc9b5c37f3cb037
  Author: Krzysztof Parzyszek <kparzysz@codeaurora.org>
  Date:   Fri Jun 30 21:21:40 2017 +0000

[ARM] Remove unused {get,set}StoredByValParamsPadding

The last uses were removed by:

  commit 8cda34f5e7e6af23910e62ab3edb430dab07799f
  Author: Tim Northover <tnorthover@apple.com>
  Date:   Wed Mar 11 18:54:22 2015 +0000

[Hexagon] Remove unused declaration getLocation

The unused declaration was introduced without a corresponding function
definition in:

  commit f5d07a05bbd41f827ccfa1bed7bfdfbab2be85dc
  Author: Krzysztof Parzyszek <kparzysz@quicinc.com>
  Date:   Mon Sep 7 14:26:48 2020 -0500

[RISCV] Refactor predicates for rvv intrinsic patterns.

This patch does the following things:

1, Add accurate Predicates in intrinsic-pseudo pattern class depending on the vector type.
2, Make vmulh, vmulhsu, vmulhu and vsmul intrinsic only able to select in v extension.

Reviewed By: craig.topper

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

[ARM] Remove unused declaration computeIssueWidth

The corresponding function definition was removed by:

  commit b2680c718fc49698e820441ed30c692a63476660
  Author: Andrew Trick <atrick@apple.com>
  Date:   Tue Jun 5 03:44:43 2012 +0000

[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