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

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

This reverts commit 879bfe6a.

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

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)).

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

> 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

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

Automatically generated by D130897. This fixed issue #58792.

Reviewed By: pengfei

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

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

Rework the change to prevent build failures. NFCI.

The failing code was submitted as
cf7a8305 and reverted via
8bd65e53.

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.

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

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

This reverts commit cf7a8305.

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

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

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_

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

Tests for D140851.

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

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

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

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

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

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

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

The file hierarchy is reorganized into:

```
├── rvv-intrinsics-autogenerated
│   ├── non-policy
│   │   ├── non-overloaded
│   │   └── overloaded
│   └── policy
│       ├── non-overloaded
│       └── overloaded
└── rvv-intrinsics-handcrafted
```

Separating auto-generated test cases and hand-craft ones. The
auto-generated ones are basic API tests generated from the intrinsic
generator [0].

This re-organization allows direct copy-and-paste from the produced
outputs of the generator in future API changes, which is discussed
and needs to be implemented towards a v1.0 RVV intrinsic.

[0] https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/181

Reviewed By: craig.topper

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

Reviewed By: lntue

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