tsan: add kBrokenAliasedMetas condition and test

This fills in a gap in the tsan_shadow_test coverage:
it is possible that the meta regions are aliased
(e.g., the heap meta region overlaps the high app meta
region). Indeed, the Aarch64_39 mapping has been
silently broken in this way for quite some time.

This CL checks whether the individual meta regions
(for low/mid/high/heap) overlap. Note that
(!kBrokenAliasedMetas && !kBrokenLinearity) implies
that MemToMeta is invertible; we cannot directly
test MetaToMem because that function does not exist.

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

Speculatively fix the Clang sphinx build

This is another attempt at getting the Sphinx build back to green. It
seems Sphinx on the build server does not like any of these, likely due
to the digit separators.

[RISCV] Remove uses of Register::isPhysicalRegister/isVirtualRegister. NFC

Use isPhysical/isVirtual methods.

[AMDGPU] Temporarily disable FeatureBackOffBarrier for GFX11

Enabling this feature exposed some incorrect codegen, where a workgroup-
scope barrier fails to properly synchronise two waves from the same
workgroup running on different SIMDs of the same CU.

Disabling FeatureBackOffBarrier causes an s_waitcnt to be emitted before
the barrier which works around the problem.

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

[LoopUnroll] Add additional DT verification test for D141487.

[OpenMP] Fix for smaller team sizes inside teams construct.

When a team nested inside a teams construct is allocated, it is
allocated to a size specified by the teams thread_limit.  In the case
where any mechanism that might not grant the full thread_limit is in
use, we may get a smaller team.  This possibility was not reflected in
the code when using the th_teams_size.nth value stored on the master
thread for the team. This value was never updated even when t_nproc on
the team itself was different.  I added a line to update it shortly
before the team is forked.

Added a simple teams test that uses KMP_DYNAMIC_MODE=random to mimic
allocating teams with sizes <= thread_limit. Eventually, this
will segfault without the fix in this commit.

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

[gn build] Port ac1ffd3caca1

[mlir][math][NFC] Migrate math dialect to the new fold API

See https://discourse.llvm.org/t/psa-new-improved-fold-method-signature-has-landed-please-update-your-downstream-projects/67618 for context

Similar to the patch for the arith dialect, the math dialects fold implementations make heavy use of generic fold functions, hence the change being comparatively mechanical and mostly changing the function signature.

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

[OpenMP] Fix unused capature and name

Summary:
This capture isn't used, get rid of it and change the name since it's
more generic now.

[clangd] Respect clang-tidy SystemHeaders option if specified

(Previous commit assumed it was always off, which is the default)

[Clang] Add requires flags to test using Linux command line

Summary:
This test uses command line tools but I forgot to add the requires
clauses. Fix it.

[mlir][sparse] Generate AOS subviews on-demand.

Previously, we generate AOS subviews for indices buffers when constructing an
immutable sparse tensor descriptor. We now only generate such subviews when
getIdxMemRefOrView is requested.

Reviewed By: Peiming

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

[AMDGCN] Update search path for device libraries

- Add support for finding device libraries in new ROCm directory
structure
- Simplify and remove the handling of legacy ROCm directory structure

Change-Id: I04da3bc9da85ced4b56b0225efb6b94448b8c5a1

Reviewed By: yaxunl

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

[NFC] Use TypeSize::geFixedValue() instead of TypeSize::getFixedSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[ARM] Limit and+csinc fold to a single use.

With glue nodes between the CMP and the CSINC, generating multiple
uses of the CMP can fail when scheduling the DAG. This limits the fold
from 90f24bef47227d58f2ccd to a single use on the CSINC, to prevent the
CMP being needed by two nodes.

[libc++][format] Fixes escaping string literals.

D140653 has the same fix, without the extra tests.

Fixes PR59763

Reviewed By: ldionne, #libc

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

[Assignment Tracking] Do not verify against an empty metadata address operand

This copies existing behaviour from other debug intrinsics to `dbg.assign`s.

Reviewed By: scott.linder

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

[NFC] Use TypeSize::getKnownMinValue() instead of TypeSize::getKnownMinSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[OpenMP] Adjust phases for AMDGPU offloading for OpenMP in save-temps mode

Currently, the behaviour of `-save-temps` changes the generated output
when offloading to AMDGPU. This is because we only have a single phase
and it contains the `-disable-llvm-passes` flags which results in
unoptimized bitcode. We need to make sure we generate another phase that
produces both the optimized and unoptimized bitcode. There used to be a
check that turned these phases into a no-op. But I believe it is more
correct to not generate them this way in the first place. Doing this
requires a bit of a hack, replacing an already generated phase action,
but it should be fine.

Reviewed By: JonChesterfield

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

[OpenMP] Add support for '--offload-arch=native' to OpenMP offloading

This patch adds support for '--offload-arch=native' to OpenMP
offloading. This will automatically generate the toolchains required to
fulfil whatever GPUs the user has installed. Getting this to work
requires a bit of a hack. The problem is that we need the ToolChain to
launch its searching program. But we do not yet have that ToolChain
built. I had to temporarily make the ToolChain and also add some logic
to ignore regular warnings & errors.

Depends on D141078

Reviewed By: jdoerfert

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

[CUDA][HIP] Support '--offload-arch=native' for the new driver

This patch applies the same handling for the `--offload-arch=native'
string to the new driver. The support for OpenMP will require some extra
logic to infer the triples from the derived architecture strings.

Depends on D141051

Reviewed By: tra

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

[CUDA][HIP] Add support for `--offload-arch=native` to CUDA and refactor

This patch adds basic support for `--offload-arch=native` to CUDA. This
is done using the `nvptx-arch` tool that was introduced previously. Some
of the logic for handling executing these tools was factored into a
common helper as well. This patch does not add support for OpenMP or the
"new" driver. That will be done later.

Reviewed By: yaxunl

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

[NFC] Use TypeSize::getKnownMinValue() instead of TypeSize::getKnownMinSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[mlir][sparse] Improve the rewriting for dense-to-sparse conversion.

Reviewed By: Peiming

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

[InstCombine] Handle PHI nodes in isOnlyCopiedFromConstantMemory()

As long as the memcpy occurs on a phi input (rather than the phi
output), we can look through phi nodes in
isOnlyCopiedFromConstantMemory().

This is split out of D136201, to only handle the case where the
address spaces are the same, and no pointer rewrite is necessary.

[mlir][NFC] Use TypeSize::getFixedValue() instead of TypeSize::getFixedSize()

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[InstCombine] Limit use walk in copied from constant fold

This fold currently performs an unbounded recursive use walk.
Make sure that we don't visit too many instructions (the limit is
chosen arbitrarily).

This is with an eye on also handling phi nodes, which will further
extend the considered use graph.

[InstCombine] Add Visited set to isOnlyCopiedFromConstantMemory()

I don't think this matters right now (because InstCombine cleans
up unreachable code early), but this will help to make sure that
we don't infinite loop once we handle phi nodes. The added test
is an example where this would happen.

Revert "llvm-reduce: Try to kill parallel workitems once we have a result."

This reverts commit 4f575620d51032cf98424c9defafe4dfc8d66f45.

I realized the test wasn't very good and when fixed, shows the
reduction doesn't work correctly. Revert the change and keep the fixed
version of the test.

[clang][NFC] Use the TypeSize::getXXXValue() instead of TypeSize::getXXXSize)

This change is one of a series to implement the discussion from
https://reviews.llvm.org/D141134.

[ARM] Don't treat arguments as producesFalseLanesZero

Invalid tail predicated loops could be formed by treating function
arguments as FalseLanesZero due to getGlobalReachingDefs not returning
any values. Make sure we check that the list of Defs is empty and if so
treat it like a unknown value.

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

[Assignment Tracking][Docs] Add new metadata to LangRef.rst

And link to the AssignmentTracking.md document which goes into more detail.

Reviewed By: jryans

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

[InstCombine] Add tests for alloca removal with phi nodes (NFC)

Tests for D136201.

[flang][NFC] Enable and migrate to new fold API

See https://discourse.llvm.org/t/psa-new-improved-fold-method-signature-has-landed-please-update-your-downstream-projects/67618 for context

This simply ports all dialects in flang to use the new fold API. These were relatively little and basically just a function signature change, since in-tree folds did not make use of any of the constant operands values.

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

[libc++][NFC] Improve consistency in status csv files

[CodeGen] Introduce a generic MEMBARRIER instruction [mostly-nfc]

This is a follow up to D141317 which extends the common code to include a target independent pseudo instruction. This is an alternative to (subset of) D92842 which tries to be as close to NFC as possible.

A couple things to call out.
* The test change in X86 is because we loose the scheduling information on the instruction. However, I think this was actually a bug in x86 since no instruction was emitted for a MEMBARRIER. Concluding that a meta instruction has latency just seems wrong?
* I intentionally left some parts of D92842 out. Specifically, several of the changes in the X86 code (data independence and outlining) appear functional, and likely worthy of their own review. Additionally, I'm not handling ARM/AArch64 at all. Those targets need the ordering whereas none of the others do. I want to get this in and tested before retrofitting in ordering to support those targets.

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

[mlir][Arith][NFC] Migrate Arith dialect to the new fold API

This is the dialect in-tree with the most `fold` method implementations by far. This patch simply changes all implementations to make use of the new signature.

Admittedly, the code readability does not get a lot better in this case, simply due to most methods making use of `constFoldBinaryOp`. I did not modify that function or its interface as part of this patch, but might be something to consider in the future.

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

[mlir][NFC] Switch dialects with no fold methods to the new fold API

These are the trivial cases which do not require any other code changes.
Changing the default might not have any semantic changes but at least guarantees that no new fold methods may be added to these dialects while migrating.

This commit is also revertible at the end of the migration

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

[libc++] Improve the implementation of std::unreachable

First, use __builtin_unreachable unconditionally. It is implemented by
all the compilers that we support. Clang started supporting it around
Clang 4, and GCC around GCC 4.10.

Also add _LIBCPP_ASSERT so that we will actually get a guaranteed crash
if we reached `std::unreachable()` and assertions have been enabled,
since that's UB that's extremely easy to catch.

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

[clangd] Suppress clang-tidy warnings for code spelled in system macros

This aligns with the default behavior of clang-tidy (which we offer no
way to override).

Fixes https://github.com/clangd/clangd/issues/1448

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

[AArch64] Add tests for selecting interleave counts for different CPUs.

Add extra tests for interleaving heuristics for different AArch64 CPUs.

[Bazel] Enable LoongArch by default, corresponding to llvmorg-16-init-16825-g85865f965d57

[Bazel] Create LoongArch target.

[flang] Support lowering of IS_CONTIGUOUS

This supports the lowering of intrinsic IS_CONTIGUOUS for array argument.
The argument of assumed rank is not supported since it is not implemented
yet as the procedure argument. Add TODO for it.

Reviewed By: PeteSteinfeld, jeanPerier

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

[X86] combinePredicateReduction - ensure non-i8 scalar type is a multiple of 8 bits

For the "all_of(setcc(x,y,eq)) -> PMOVMSKB(PCMPEQB())" fold, we failed to ensure that we could safely bitcast to <X x i8>, which in particular failed with boolean types

Thanks to @lerno for catching this and providing the test case

[IRBuilder] Use canonical i64 type for insertelement index used by vector splats.

Instcombine prefers this canonical form (see getPreferredVectorIndex),
as does IRBuilder when passing the index as an integer so we may as
well use the prefered form from creation.

NOTE: All test changes are mechanical with nothing else expected
beyond a change of index type from i32 to i64.

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

[Bazel] Update `//llvm:TargetParser` for `RISCVTargetParserDef.inc`

It has been introduced since llvmorg-16-init-16838-gac1ffd3caca1

[AArch64][SVE] Avoid AND operation if both side are splat of i1 or PTRUE

If both sides of AND operations are i1 splat_vectors or PTRUE node then we can
produce just i1 splat_vector as the result.

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

[GVNHoist] Convert test to opaque pointers (NFC)

Adjust the GEPs to be non-trivial, to preserve test intent.

[Attributor] Convert some tests to opaque pointers (NFC)

Check lines were regenerated for these.

The alignment changes in byval-2. look suspicious at first glance,
but actually only propagate pre-existing UB.

llvm-reduce: Try to kill parallel workitems once we have a result.

The current reduction logic tries to reproduce what a serial reduction
would produce, and just takes the first one that is still
interesting. We still have to wait for all others to complete though,
which at that point is just a waste.

This helps speed things up with long running reducers, which I
frequently have. e.g. for the added sleep test on my system, it took
about 8 seconds before this change and about 4 after.

https://reviews.llvm.org/D138953

[include-cleaner] Improve header spelling in the presence of links

HeaderSearch uses FileEntry::getName() to determine the best spelling of a
header. FileEntry::getName() is now the name of the *last* retrieved ref.
This means that when FileManager::getFile() hits an existing inode through a new
path, it changes the spelling of that header.

In the absence of explicit logic to track the preferred name(s) of header files,
we should avoid gratuitously calling getFile() with paths different than how
the header was originally included, such as the result of realpath().

The originally-specified path should be fine here:
 - if the same filemanager is being used for record/analysis, we'll hit the
   filename cache
 - if a different filemanager is being used e.g. preamble scenario, we should
   get the same result unless either the working directory has changed (which it
   shouldn't, else many other things will fail) or the file has gone/changed
   inode (in which case the old method doesn't work either)

Needless to say this is fragile, but talking to @kadircet offline, it's good
enough for our purposes for now.

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

[CodeExtractor] Convert tests to opaque pointers (NFC)

Keeping bitcasts to preserve test behavior.

[mlir] Add a new fold API using Generic Adaptors

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch implements the required foldHook changes and the TableGen machinery for generating `fold` method signatures using `FoldAdaptor` for ops, based on the value of `useFoldAPI` of the dialect. It may be one of 2 values, with convenient named constants to create a quasi enum. The new `fold` method will then be generated if `kEmitFoldAdaptorFolder` is used.

Since the new `FoldAdaptor` approach is strictly better than the old signature, part of this patch updates the documentation and all example to encourage use of the new `fold` signature.
Included are also tests exercising the new API, ensuring proper construction of the `FoldAdaptor` and proper generation by TableGen.

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

[mlir][tblgen] Generate generic adaptors for Ops

This is part of the RFC for a better fold API: https://discourse.llvm.org/t/rfc-a-better-fold-api-using-more-generic-adaptors/67374

This patch implements the generation of generic adaptors through TableGen. These are essentially a generalization of Adaptors, as implemented previously, but instead of indexing into a `mlir::ValueRange`, they may index into any container, regardless of the element type. This allows the use of the convenient getter methods of Adaptors to be reused on ranges that are the result of some kind of mapping functions of an ops operands.
In the case of the fold API in the RFC, this would be `ArrayRef<Attribute>`, which is a mapping of the operands to their possibly-constant values.

Implementation wise, some special care was taken to not cause a compile time regression, nor to break any kind of source compatibility.
For that purpose, the current adaptor class was split into three:
* A generic adaptor base class, within the detail namespace as it is an implementation detail, which implements all APIs independent of the range type used for the operands. This is all the attribute and region related code. Since it is not templated, its implementation does not have to be inline and can be put into the cpp source file
* The actual generic adaptor, which has a template parameter for the range that should be indexed into for retrieving operands. It implements all the getters for operands, as they are dependent on the range type. It publicly inherits from the generic adaptor base class
* A class named as adaptors have been named so far, inheriting from the generic adaptor class with `mlir::ValueRange` as range to index into. It implements the rest of the API, specific to `mlir::ValueRange` adaptors, which have previously been part of the adaptor. This boils down to a constructor from the Op type as well as the verify function.

The last class having the exact same API surface and name as Adaptors did previously leads to full source compatibility.

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

[GVNHoist] Regenerate test checks (NFC)

[NFC][AMDGPU] Pre-commit BFI test.

[AMDGPU] Use MCInstrDesc::getSize. NFC.

[GVN] Convert tests to opaque pointers (NFC)

[LoongArch] Fix undefined behavior: left shift of negative value

Fix undefined behavior in `decodeSImmOperand` where we were left shifting
a signed value.

llvm-reduce: Fix assertion on blockaddress during function reduction

Just avoid crashing for now, we should be able to replace the blockaddresses
themselves.

BlockAddress::handleOperandChangeImpl assumes it can cast to Function.
The verifier seems nonexistent and the langref isn't particularly explicit
on what's allowed as a blockaddress operand. As far as I can tell bugpoint
isn't doing anything to handle this.

Something low level is broken with BlockAddress handling,
demonstrated by reduce-functions-blockaddress-wrong-function.ll.
The BasicBlock destructor of the deleted function is triggering replacement
of blockaddresses for the kept function in some cases. I've only half debugged
this but it seems like blockaddress is handled too-specially compared to other
Constants. I have tentative patches to allow any constant to be a blockaddress
input, but having the verifier check if it's really a function/block.

https://reviews.llvm.org/D140909

[flang] Support C1553 about BIND(C) function result

As Fortran 2018 C1553, if with BIND(C), the function result shall be an
interoperable scalar variable. As Fortran 2018 18.3.4(1), the
interoperable scalar variable is not a coarray, has neither the
ALLOCATABLE nor the POINTER attribute, and if it is of type character its
length is not assumed or declared by an expression that is not a constant
expression.

As Fortran 2018 18.3.1(1), if the type is character, the length type
parameter is interoperable if and only if its value is one.

Reviewed By: PeteSteinfeld, jeanPerier

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

[docs] Apply previous sphinx fix to its actual source

This clang-format documentation file is auto-generated from Format.h,
so the fix should be applied there, or else it will be overwritten
whenever Format.h is modified and that file is regenerated.

Speculatively fix the Clang sphinx build

This file builds correctly for me locally, but gives a warning about
not being able to lex the binary literal as C++ code.

This should fix the issue found by:
https://lab.llvm.org/buildbot/#/builders/92/builds/38522

[Test] Regenerate checks in fold.ll using auto-update script

[clang][Interp][NFC] Remove code duplication in VisitRecordInitializer

We can just use the regular VisitCallExpr logic here, since we have the
pointer to initialize already on the stack.

[clang][Interp][NFC] Add an assertion

This is unnecessary in the current state of the interpreter, but will ne
important later.

[CVP] Add tests for condition constraint at use (NFC)

[Test] Add complementary test for umin_seq

[ReleaseNotes] Add Neoverse V2 CPU to LLVM's release notes

This new CPU was mentioned in Clang's release notes, but was missing
from LLVM's.

Reviewed By: dmgreen

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

[include-mapping] Fix the instructions for running stdlib recognizer. Mention python command explicitly. Remove angle brackets.

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

Revert "Revert "[clang-format] Add an option for breaking after C++11 attributes""

This reverts commit 879bfe6a979295f834b76df66b19a203b93eed0f.

owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.

[docs] Add newline in clang release notes.

[clang-format][doc] Fix doc format for IntegerLiteralSeparator

[Test] Add test showing missing canonicalization opportunity in SCEV

We could have same SCEVs for the following expressions:
  zext(umin(x, y)) and umin(zext(x), zext(y));
  zext(umax(x, y)) and umax(zext(x), zext(y))
  sext(smin(x, y)) and smin(zsxt(x), sext(y));
  sext(smax(x, y)) and smax(sext(x), sext(y)).

[mlir][arith] Optimize arith.cmpi based on integer range analysis.

Add a pass which do arith dialect ops optimization based on integer range analysis (only cmpi for now).

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

Perform access checking to private members in simple requirement.

> Dependent access checks.

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

We previously ignored dependent access checks to private members.
These are visible only to the `RequiresExprBodyExpr` (through `PerformDependentDiagnositcs`) and not to the individual requirements.

---

> Non-dependent access checks.
Fixes: https://github.com/llvm/llvm-project/issues/53334
Access to members in a non-dependent context would always yield an
invalid expression. When it appears in a requires-expression, then this
is a hard error as this would always result in a substitution failure.

https://eel.is/c++draft/expr.prim.req#general-note-1
> Note 1: If a requires-expression contains invalid types or expressions in its requirements, and it does not appear within the declaration of a templated entity, then the program is ill-formed. — end note]
> If the substitution of template arguments into a requirement would always result in a substitution failure, the program is ill-formed; no diagnostic required.

The main issue here is the delaying of the diagnostics.
Use a `ParsingDeclRAIIObject` creates a separate diagnostic pool for diagnositcs associated to the `RequiresExprBodyDecl`.
This is important because dependent diagnostics should not be leaked/delayed to higher scopes (Eg. inside a template function or in a trailing requires). These dependent diagnostics must be attached to the `DeclContext` of the parameters of `RequiresExpr` (which is the `RequiresExprBodyDecl` in this case).
Non dependent diagnostics, on the other hand, should not delayed and surfaced as hard errors.

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

[clang][Interp][NFC] Print Pointee address of Pointer

[compiler-rt] support armv5t, armv6

The legwork for these was done by https://reviews.llvm.org/D138725. Here we're
just adding the arch names to the cmake files and linking them to
arm_min_SOURCES.

Reviewed By: MaskRay

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

[X86] Add scheduling info of CodeGenOnly but encodable instructions for AlderlakeP model

Automatically generated by D130897. This fixed issue #58792.

Reviewed By: pengfei

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

Revert "[DWARFLibrary] Add support to re-construct cu-index"

This reverts commit 73712c8790a93c29e513f5e201f92ac5b2370cf9. It causes
a MemorySanitizer error in LLVM testsuite. See
the discussion on https://reviews.llvm.org/D137882 for details.

[TargetParser]  Generate the defs for RISCV CPUs using llvm-tblgen.

Rework the change to prevent build failures. NFCI.

The failing code was submitted as
cf7a8305a2b4ddfd299c748136cb9a2960ef7089 and reverted via
8bd65e535fb33bc48805bafed8217b16a853e158.

The rework in this new commit prevents failures like the following:

FAILED: tools/clang/lib/Basic/CMakeFiles/obj.clangBasic.dir/Targets/RISCV.cpp.o
/usr/bin/c++  [bunch of non interesting stuff]  -c <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp
In file included from <path-to>/llvm-project/clang/lib/Basic/Targets/RISCV.cpp:19:
<path-to>/llvm-project/llvm/include/llvm/TargetParser/RISCVTargetParser.h:29:10: fatal error: llvm/TargetParser/RISCVTargetParserDef.inc: No such file or directory
  29 | #include "llvm/TargetParser/RISCVTargetParserDef.inc"
     |          ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

These failures happen because the library LLVMTargetParser depends on
RISCVTargetParserTableGen, which is a tablegen target that generates
the list of CPUs in
llvm/TargetParser/RISCVTargetParserDef.inc. This *.inc file is
included by the public header file
llvm/TargetParser/RISCVTargetParser.h.

The header file llvm/TargetParser/RISCVTargetParser.h is also used in
components (clangDriver and clangBasic) that link into
LLVMTargetParser, but on some configurations such components might end
up being built before TargetParser is ready.

The fix is to make sure that clangDriver and clangBasic depend on the
tablegen target RISCVTargetParserTableGen, which generates the .inc
file whether or not LLVMTargetParser is ready.

WRT the original patch at https://reviews.llvm.org/D137517, this
commit is just adding RISCVTargetParserTableGen in the DEPENDS list of
clangDriver and clangBasic.

[BOLT][AArch64] add lock to FixRelaxations pass

Since the pass is multithreaded, BC.Ctx must be protected. Otherwise we get crashes when processing.

Reviewed by: yota9

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

[RISCV][NFC] Update V spec section numbers

The section numbers got reshuffled around between v0.10 and [[ https://github.com/riscv/riscv-v-spec/blob/v1.0/v-spec.adoc |  v1.0 of the spec ]], this updates references in comments to refer to their version in v1.0.

Reviewed By: craig.topper

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

[AArch64] Add REQUIRES: aarch64-registered-target to aarch64-targetattr-arch.c. NFC

Revert "[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen."

This reverts commit cf7a8305a2b4ddfd299c748136cb9a2960ef7089.

[InstCombine] Handle assume(X & Pow2 != 0) in computeKnownBits()

If we know that X & Pow2 != 0, then the bit at that position is
known one.

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

[LoongArch] Refine the condition to return Match_RequiresAMORdDifferRkRj in AsmParser. NFC

This can suppress compilation warning like `enumerated mismatch in conditional expression`.

See:
https://lab.llvm.org/staging/#/builders/236/builds/645/steps/6/logs/warnings__1_

[MLIR][Tensor] Fix example for pack/unpack (NFC)

[LoopVectorize] Clear cache of `LoopAccessInfoManager`

LAI is cached during the LoopDistribute pass, and is later re-used during LoopVectorize. The problem is that LoopVectorize changes SCEV, and the cached LAI does not get updated. Hence, when re-using the cached LAI, it references an invalid SCEV.

Fixes #59319

Reviewed By: fhahn

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

[InstCombine] Add tests for icmp ne non-zero power of 2; NFC

Tests for D140851.

[TargetParser] Generate the defs for RISCV CPUs using llvm-tblgen.

This patch removes the file `llvm/include/llvm/TargetParser/RISCVTargetParser.def` and replaces it with a tablegen-generated `.inc` file out of `llvm/lib/Target/RISCV/RISCV.td`.

The module system has been updated to make sure we can build clang/llvm with `-DLLVM_ENABLE_MODULES=On`

Reviewed By: craig.topper

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

[OpenMP][FIX] Avoid performance regression accidentally introduced

[AArch64] Make -march and target(arch=..) attributes imply dependent features

Specifying an architecture revision should also add feature strings for
any dependent default extensions. Otherwise the new checks for
target-dependent features for acle intrinsics from D134353 and D132034
can fail.

This patch does that in setFeatureEnabled, similar to the addition of
dependent architecture revisions. +sve also needs to be added to armv9
architectures in the target parser, as it is implied by +sve2.

Fixes #59911

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

Reland "[CMake][LoongArch] Add LoongArch to LLVM_ALL_TARGETS so it is built by default"

This follows the [[ https://discourse.llvm.org/t/rfc-promoting-the-loongarch-backend-from-experimental-to-official/67506/ | RFC ]].

Follow-on commits will add appropriate release notes changes etc.

Submit this now and in a minimal form so there is reasonable time before
16.0.0 is branched to resolve any issues arising from e.g. the backend
being exposed on different compiler/sanitizer setups.

The current builder for LoongArch is on the [[ https://lab.llvm.org/staging/#/builders/236 | staging area ]].

Reviewed By: jyknight, MaskRay, echristo, myhsu, tstellar, arsenm

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

[flang] Lowering and implementation for extends_type_of

Add implementation and loweirng for the extends_type_of
intrinsic.

The standard mentions this: otherwise if the dynamic type of A or MOLD is
extensible, the result is true if and only if the dynamic type of A is an
extension type of the dynamic type of MOLD. Which could be interpreted that
`extends_type_of(a, a)` could be false since a type is not an extension of
itself. Gfortran result for this is `true` so the same behavior is applied
here as well.

Depends on D141364

Reviewed By: jeanPerier, PeteSteinfeld

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

[flang] Lowering and implementation for same_type_as

The test performed by same_type_as does not consider kind type
parameters. If an exact match is not found, the name of the
derived type is compared. The name in the runtime info does not include
the kind type parameters as it does in the mangled name.

Reviewed By: jeanPerier, PeteSteinfeld

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

[flang] Only deallocate intent(out) allocatable through runtime if allocated

Deallocation of intent(out) allocatable was done in D133348. This patch adds
an if guard when the deallocation is done through a runtime call. The runtime
is crashing if the box is not allocated. Call the runtime only if the box is
allocated. This is the case for derived type, polymorphic and unlimited
polymorphic entities.

Reviewed By: PeteSteinfeld

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

[PowerPC][GISel] Select sync instructions required by atomic operations

This is part of selecting `G_ATOMIC*` instructions. Select `isync`, `sync` and `lwsync` in GISel.

Reviewed By: arsenm

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

[LoongArch] Fixed llvm/test/CodeGen/LoongArch/intrinsic.ll test failure when EXPENSIV_CHECK is enabled [1].

Specifically:
```
*** Bad machine code: Using an undefined physical register ***
- function:    movgr2fcsr
- basic block: %bb.0 entry (0x1af5e60)
- instruction: MOVGR2FCSR $fcsr1, %0:gpr
- operand 0:   $fcsr1

*** Bad machine code: Using an undefined physical register ***
- function:    movfcsr2gr
- basic block: %bb.0 entry (0x133fae0)
- instruction: %0:gpr = MOVFCSR2GR $fcsr1
- operand 1:   $fcsr1
```

By building MachineInstructions, the state of the register is
clarified, and the error caused by using undefined physical registers
is fixed.

[1]: https://lab.llvm.org/buildbot/#/builders/16/builds/41677