Modular just announced a new language called Mojo. This patch adds an entry in the language list in LLDB for minimal support (e.g. being able to create a TypeSystem for this language). We will later add debug info entries when the language matures.

Small clean up to keep a single version of getAllocTypeAttributeString
which was duplicated locally.

Summary;
This was changed a long time ago to drop the `LLVM_` prefix.

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

Cleanup profile reader classes to prepare for complex refactoring as propsed in D147740 (Use MD5 as key for profile map). Change is too complicated so I am cleaning up the reader implementation first with these goals.
-  Reduce duplicated/similar logic
-  Reduce virtual functions, changing them to non-virtual
-  Reduce unnecessry checks, indirections, and dead writes.

This is patch 1/n. This patch refactors NameTable

Explaining several decisions here

1. useMD5() means whether  names of the profiles (the ProfileMap) are represented as MD5. It is NOT whether the input profile format is MD5. This function is an interface for IPO passes to decide whether to match function names or function MD5. There are two motives here:
(a) Eventually we want to use MD5 to represent all function contexts because it is much faster to use it as a key for lookup tables (prototype implementation D147740), so in compilation mode we call setProfileUseMD5() to force use MD5. While in tools mode (llvm-profdata) we want to keep the function name info if it's in the input profile.
(b) We also propose to allow multiple name tables and profile sections in ExtBinary format, and it could consist of name tables with or without using MD5, in this case MD5 prevails and other name tables are converted to MD5.

2. MD5 handling logic is pushed up to BinaryReader base class, because this trades a non-devirtualized virtual function call with a predictable branch. ReadStringFromTable() accounts for >5% time when loading a full 1 GB profile, it should not be virtual.

Reviewed By: davidxl

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

"any" is actualy any resonably recent GLIBC.

This is part of an on-going migration to adopt Properties inside MLIR.

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

A new forwarding constructor is introduced on the adaptor to take directly
an OpaqueProperties object and do the nullptr checking and casting to avoid
the boilerplate at callsites.

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

This is at odds with the coding standard.
Quoting https://llvm.org/docs/CodingStandards.html#anonymous-namespaces
> Because of this, we have a simple guideline: make anonymous namespaces
> as small as possible, and only use them for class declarations.

Reviewed By: MaskRay

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

Applies ThinLTO cloning decisions made during the thin link and
recorded in the summary index to the IR during the ThinLTO backend.

Depends on D141077.

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

Reviewers: danalbert, enh, pirama, srhines

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

In a `__asm` block, a symbol reference is usually a memory constraint
(indirect TargetLowering::C_Memory) [LOOP]. CALL and JUMP instructions are special
that `__asm call k` can be an address constraint, if `k` is a function.

Clang always gives us indirect TargetLowering::C_Memory and need to convert it
to direct TargetLowering::C_Address. D133914 implements this conversion, but
does not consider JMP or case-insensitive CALL. This patch implements the missing
cases, so that `__asm jmp k` (`jmp ${0:P}`) will correctly lower to `jmp _k`
instead of `jmp dword ptr [_k]`.

(`__asm call k` lowered to `call dword ptr ${0:P}` and is fixed by D149695 to
lower to `call ${0:P}` instead.)

[LOOP]: Some instructions like LOOP{,E,NE} and Jcc always use an address
constraint (`loop _k` instead of `loop dword ptr [_k]`).

After this patch and D149579, all the following cases will be correct.
```
int k(int);
int (*kptr)(int);
...
__asm call k; // correct without this patch
__asm CALL k; // correct, but needs this patch to be compatible with D149579
__asm jmp k;  // correct, but needs this patch to be compatible with D149579
__asm call kptr; // will be fixed by D149579.  "Broken case" in clang/test/CodeGen/ms-inline-asm-functions.c
__asm jmp kptr;  // will be fixed by this patch and D149579
```

Reviewed By: pengfei

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

Minor logic mistake. This caused TestObjCClassMethod to fail.

Use the templated GetPropertyAtIndexAs helper for ArchSpec.

Use the templated GetPropertyAtIndexAs helper for LanguageType.

Reported by Coverity:

1. Inside "ASTReader.cpp" file,  in clang::ASTReader::FindExternalLexicalDecls(clang::DeclContext const *, llvm::function_ref<bool (clang::Decl::Kind)>, llvm::SmallVectorImpl<clang::Decl *> &): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type pair.

2. Inside "ASTReader.cpp" file, in clang::ASTReader::ReadAST(llvm::StringRef, clang::serialization::ModuleKind, clang::SourceLocation, unsigned int, llvm::SmallVectorImpl<clang::ASTReader::ImportedSubmodule> *): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type DenseMapPair.

3. Inside "CGOpenMPRuntimeGPU.cpp" file, in clang::CodeGen::CGOpenMPRuntimeGPU::emitGenericVarsEpilog(clang::CodeGen::CodeGenFunction &, bool): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type pair.

4. Inside "ASTWriter.cpp" file, in clang::ASTWriter::WriteHeaderSearch(clang::HeaderSearch const &): Using the auto keyword without an & causes a copy.

auto_causes_copy: Using the auto keyword without an & causes the copy of an object of type UnresolvedHeaderDirective.

Reviewed By: tahonermann

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

This reverts commit 8b8466fd.

This is causing size regressions with -Oz and FullLTO. Revert while I
come up with a repro.

This reverts commit 6f29d1ad.

https://reviews.llvm.org/D149768 is causing size regressions for -Oz
with FullLTO, and I'm reverting that one while investigating. This
commit depends on that one, so it needs to be reverted as well.

This removes the need for a custom libc++ build to have a basic set of PSTL algorithms.

Reviewed By: ldionne, #libc

Spies: miyuki, libcxx-commits, arichardson

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

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate

After rewriting:
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate

Reviewed By: kiranchandramohan

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



Co-authored-by: Isaac Perry <isaac.perry@arm.com>

This reverts commit 597d8563.

This reverts commit f09807ca, restoring
bfe72059 and follow on fix
e3e6bc69, now that the nondeterminism
has been addressed by D149924.

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

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```

After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```

Co-authored-by: Isaac Perry <isaac.perry@arm.com>

Reviewed By: kiranchandramohan

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

This reverts commit 5faf45a3.
Once again arcanist stripped the co-author metadata.  I'm going to add it to the revision description and try one last time.

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```

After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```

Reviewed By: kiranchandramohan

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

This reverts commit eaf7d978.
Arcanist stripped co-author data from initial commit.

We were modeling these as if the index type was always e8, but the actual
lowering uses the data type width if legal.  We also weren't accounting for
i64 on xlen32 correctly.

Noticed via inspection while working on the shuffle/buildvec lowering.  Note
that this costing is also wrong in a more major way - we don't actually use
a constant pool load in many cases.  But that's a separate issue.

Update OpenACC update construct lowering to create
the data operand operations for host and device clauses.

Depends on D149909

Reviewed By: razvanlupusoru, jeanPerier

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

Introduce acc.update_host and acc.update_device as data
operands operation to be used by the acc.update op.

Reviewed By: razvanlupusoru, jeanPerier

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

Reported by Coverity:

  In clang::ASTContext::hasUniqueObjectRepresentations(clang::QualType, bool): Return value of function which returns null is dereferenced without checking.

  (Ty->isMemberPointerType()) {
      	//returned_null: getAs returns nullptr.
      	//var_assigned: Assigning: MPT = nullptr return value from getAs.
      const auto *MPT = Ty->getAs<MemberPointerType>();

     //dereference: Dereferencing a pointer that might be nullptr MPT when calling getMemberPointerInfo. (The virtual call resolves to
     <unnamed>::ItaniumCXXABI::getMemberPointerInfo.)
      return !ABI->getMemberPointerInfo(MPT).HasPadding;
    }

ABIs assume the parameter passed to `getMemberPointerInfo` is non-null.
This patch checks type by doing a `if (const auto *MPT = Ty->getAs<MemberPointerType>())` instead.

Reviewed By: erichkeane

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

Addresses the same issue as the following abandoned revision: D104391.

Rewrite leading declarative allocations so they are nested within their respective executable allocate directive

Original:
```
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPDeclarativeAllocate
ExecutionPartConstruct -> OpenMPExecutableAllocate
```

After rewriting:
```
ExecutionPartConstruct -> OpenMPExecutableAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
| ExecutionPartConstruct -> OpenMPDeclarativeAllocate
```

Reviewed By: kiranchandramohan

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

This patch uses the changed interface in D149972 to make these classes
move-only. The `Port` class could be further refined to be
construct-only in a future patch, but for now this makes it more
difficult to misuse the interface.

Depends on D149972

Reviewed By: JonChesterfield

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

This patch replaces the existing `cpp::optional` type with a newer
version that has more features. This class is heavily inspired by the
old `llvm::Optional` class. Currently the limitations of this class is
that we only handle types with trivial constructors or operators.

Reviewed By: sivachandra

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