Changes

NFC. Remove obsolete SimpleAnalysis infrastructure
Apparently cache of AliasSetTrackers held by LICM was the only user of 
SimpleAnalysis infrastructure. Now, given that we no longer have that 
cache, this infrastructure is obsolete and, taking into account its 
nature, we don't want any new solutions to be based on it.
Reviewers: asbirlea, fhahn, efriedma, reames
Reviewed-By: asbirlea
Differential Revision: https://reviews.llvm.org/D73085

NFC. Add PR44320 IR test case.

[lldb/Test] Don't add a check-* target as dependency in
add_lit_testsuite
This causes the toplevel "test-depends" target, which should only build 
all the dependencies necessary for running tests, to suddenaly also run 
the check-lldb-repro-capture tests.
Instead add check-lldb-repro-capture as a dependency to check-lldb-repro 
with a separate explicit add_dependencies call.

[Concepts] Profile TypeConstraints in ProfileTemplateParameterList
Profile TypeConstraints in ProfileTemplateParameterList so we can
distinguish between partial specializations which differ in their
TemplateParameterList type constraints

[DWARF] Support 64-bit DWARF in .debug_pubnames and similar tables.
Differential Revision: https://reviews.llvm.org/D73103

Revert "[Concepts] Profile TypeConstraints in
ProfileTemplateParameterList"
This temporarily reverts commit 0e3ae353a47273825cd2f20f4777dcb5731cf8ec
because of a potential bug.

[Concepts] Profile TypeConstraints in ProfileTemplateParameterList
Profile TypeConstraints in ProfileTemplateParameterList so we can
distinguish between partial specializations which differ in their
TemplateParameterList type constraints.
Recommit, now profiling the IDC so that we can deal with situations
where the TemplateArgsAsWritten are nullptr (happens when canonicalizing
type constraints).

[DWARF] Get rid of DWARFDebugNames::HeaderPOD. NFC.
This structure was used to get the size of the fixed-size part of a Name 
Index header for 32-bit DWARF. It is unsuitable for 64-bit DWARF because 
the size of the unit length field is different.
Differential Revision: https://reviews.llvm.org/D73040

[DWARF] Eliminate the DWARFDebugNames::Header::Padding field.
The padding field is reserved for DWARF and does not contain any useful 
information. No need to read, store and report it.
Differential Revision: https://reviews.llvm.org/D73042

[SSAUpdater] Don't call ValueIsRAUWd upon single use replacement
It is incorrect to call ValueHandleBase::ValueIsRAUWd when only one use 
is replaced since it simply violates semantics of the callback and leads 
to bugs like PR44320.
Previously this call was used specifically to keep LICM's cache of 
AliasSetTrackers up to date across passes (as PR36801 showed, even for 
that purpose it didn't work properly), but since LICM doesn't have that 
cache anymore, we can safely remove this incorrect call with no 
repercussions.
This patch fixes https://bugs.llvm.org/show_bug.cgi?id=44320
Reviewers: asbirlea, fhahn, efriedma, reames
Reviewed-By: asbirlea
Differential Revision: https://reviews.llvm.org/D73089

[LLD][COFF] Enable linking of __declspec(selectany) symbols from Clang
and GCC
When annotating a symbol with __declspec(selectany), Clang assigns it 
comdat 2 while GCC assigns it comdat 3. This patch enables two object 
files that contain a __declspec(selectany) symbol, one created by gcc 
and the other by clang, to be linked together instead of issuing a 
duplicate symbol error.
Differential Revision: https://reviews.llvm.org/D73139

[llvm-exegesis] Restrict to allowed back-to-back instructions in
SerialSnippetGenerator.
Summary: Followup to D73161.
Reviewers: gchatelet, mstojanovic
Subscribers: tschuett, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73256

[lldb][NFC] Rename ClangASTContext to TypeSystemClang
Summary: This commit renames ClangASTContext to TypeSystemClang to
better reflect what this class is actually supposed to do
(implement the TypeSystem interface for Clang). It also gets rid of the
very confusing situation that we have both a
`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes
causes Clang people to think I'm fiddling with Clang's ASTContext when
I'm actually just doing LLDB work).
I also have plans to potentially have multiple clang::ASTContext
instances associated with one ClangASTContext so the ASTContext naming
will then become even more confusing to people.
Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere,
davide, espindola, jdoerfert, xiaobai
Reviewed By: clayborg, labath, xiaobai
Subscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay,
arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere,
lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72684

[Object][test] - Remove readobj-elf-versioning.test and support files.
`readobj-elf-versioning.test` was added in rL152436 and checks how
llvm-readobj --dyn-syms prints versioned symbols. We test the same in
`llvm-readobj\ELF\dyn-symbols.test` currently.
This patch removes the test and 4 more support files from Inputs.
Differential revision: https://reviews.llvm.org/D73163

[llvm-readobj][test] - Add a check for --dyn-syms.
We have a `-dyn-symbols` option. It has a `--dyn-syms` alias that is not
tested in llvm-readobj tests currently.
There was a Object/readobj-elf-versioning.test where it is used, but
I've removed it in D73163. And also it is not the right place to test it
anyways.
Differential revision: https://reviews.llvm.org/D73164

[test] Avoid loop-unroll.c test getting confused by fadd in git revision
Differential Revision: https://reviews.llvm.org/D73162

[lldb][NFC] Delete empty file source/Host/linux/ProcessLauncherLinux.cpp
This was renamed in 816ae4b0dfac9a2bd964e8c4dae6dd7183ceb92a but it
seems the commit only emptied the file instead of deleting it.

Revert "[Concepts] Placeholder constraints and abbreviated templates"
This reverts commit e57a9abc4b01fa69fe81ace8df70517983b6cbac.
Parser/cxx2a-placeholder-type-constraint.cpp has MSan failures.
Present at 7b81c3f8793d30a4285095a9b67dcfca2117916c: 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17133/steps/check-clang%20msan/logs/stdio 
not present at eaa594f4ec54eba52b03fd9f1c789b214c66a753: 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap-msan/builds/17132/steps/check-clang%20msan/logs/stdio
Stack trace:
```
==57032==WARNING: MemorySanitizer: use-of-uninitialized-value
   #0 0xccfe016 in clang::AutoTypeLoc::getLocalSourceRange() const
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/include/clang/AST/TypeLoc.h:2036:19
   #1 0xcc56758 in CheckDeducedPlaceholderConstraints(clang::Sema&,
clang::AutoType const&, clang::AutoTypeLoc, clang::QualType)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4505:56
   #2 0xcc550ce in clang::Sema::DeduceAutoType(clang::TypeLoc,
clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4707:11
   #3 0xcc52407 in clang::Sema::DeduceAutoType(clang::TypeSourceInfo*,
clang::Expr*&, clang::QualType&, llvm::Optional<unsigned int>, bool)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaTemplateDeduction.cpp:4457:10
   #4 0xba38332 in
clang::Sema::deduceVarTypeFromInitializer(clang::VarDecl*,
clang::DeclarationName, clang::QualType, clang::TypeSourceInfo*,
clang::SourceRange, bool, clang::Expr*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11351:7
   #5 0xba3a8a9 in
clang::Sema::DeduceVariableDeclarationType(clang::VarDecl*, bool,
clang::Expr*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11385:26
   #6 0xba3c520 in clang::Sema::AddInitializerToDecl(clang::Decl*,
clang::Expr*, bool)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Sema/SemaDecl.cpp:11725:9
   #7 0xb39c498 in
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::ForRangeInit*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2399:17
   #8 0xb394d80 in
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*,
clang::Parser::ForRangeInit*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2128:21
   #9 0xb383bbf in
clang::Parser::ParseSimpleDeclaration(clang::DeclaratorContext,
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&, bool,
clang::Parser::ForRangeInit*, clang::SourceLocation*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:1848:10
   #10 0xb383129 in
clang::Parser::ParseDeclaration(clang::DeclaratorContext,
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&,
clang::SourceLocation*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/llvm/include/llvm/ADT/PointerUnion.h
   #11 0xb53a388 in
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*,
clang::Parser::ParsedAttributesWithRange&)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:221:13
   #12 0xb539309 in
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, clang::Parser::ParsedStmtContext, clang::SourceLocation*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:106:20
   #13 0xb55610e in clang::Parser::ParseCompoundStatementBody(bool)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:1079:11
   #14 0xb559529 in
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseStmt.cpp:2204:21
   #15 0xb33c13e in
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::LateParsedAttrList*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1339:10
   #16 0xb394703 in
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&,
clang::DeclaratorContext, clang::SourceLocation*,
clang::Parser::ForRangeInit*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseDecl.cpp:2068:11
   #17 0xb338e52 in
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1099:10
   #18 0xb337674 in
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:1115:12
   #19 0xb334a96 in
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:935:12
   #20 0xb32f12a in
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&,
bool)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/Parser.cpp:686:12
   #21 0xb31e193 in clang::ParseAST(clang::Sema&, bool, bool)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Parse/ParseAST.cpp:158:20
   #22 0x80263f0 in clang::FrontendAction::Execute()
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/FrontendAction.cpp:936:8
   #23 0x7f2a257 in
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/Frontend/CompilerInstance.cpp:965:33
   #24 0x8288bef in
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:290:25
   #25 0xad44c2 in cc1_main(llvm::ArrayRef<char const*>, char const*,
void*)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/cc1_main.cpp:239:15
   #26 0xacd76a in ExecuteCC1Tool(llvm::ArrayRef<char const*>)
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:325:12
   #27 0xacc9fd in main
/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm-project/clang/tools/driver/driver.cpp:398:12
   #28 0x7f7d82cdb2e0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
   #29 0xa4dde9 in _start
(/b/sanitizer-x86_64-linux-bootstrap-msan/build/llvm_build_msan/bin/clang-11+0xa4dde9)
```

[llvm-exegesis] Allow the randomizer to fail nicely...
Summary:
... instead of crashing. On typical exmaple is when there are no
available registers.
Reviewers: gchatelet
Subscribers: tschuett, mstojanovic, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73196

[mlir] Shrink-wrap anonymous namespaces around the classes it's supposed
to enclose. NFC.
The coding standards prefer smaller anonymous namespaces with free 
functions just being static and in the global namespace.

[NFC][DwarfDebug] Use proper analog GNU attribute for the pc address
The low_pc is analog to the DW_AT_call_return_pc, since it describes the
return address after the call. The DW_AT_call_pc is the address of the
call instruction, and we don't use it at the moment.
Differential Revision: https://reviews.llvm.org/D73173

[LLD] [COFF] Silence a GCC warning about an unused variable. NFC.

[SelectionDAG] Compute Known + Sign Bits - merge INSERT_SUBVECTOR
known/unknown index paths
Match the approach in SimplifyDemandedBits where we calculate the
demanded elts and then have a common path for the
ComputeKnownBits/ComputeNumSignBits call, additionally we only ever need
original demanded elts of the base vector even if the index is unknown.

[SelectionDAG] ComputeKnownBits - merge EXTRACT_VECTOR_ELT known/unknown
index paths
Match the approach in SimplifyDemandedBits/ComputeNumSignBits where we
calculate the demanded elts and then have a common path for the
ComputeKnownBits call.

[FileCheck] Strengthen error checks in unit tests
Summary: This commit adds error checking beyond UndefVarError and fix a
number of Error/Expected related idioms:
- use (EXPECT|ASSERT)_THAT_(ERROR|EXPECTED) instead of errorToBool or
 boolean operator
- ASSERT when a further check require the check to be successful to give
 a correct result
Reviewers: jhenderson, jdenny, probinson, grimar, arichardson, rnk
Reviewed By: jhenderson
Subscribers: llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D72914

[llvm-exegesis] Don't use unsupported aliasing instructions
Since some instruction types aren't allowed as the main instruction also 
don't allow them for aliasing instructions.
Differential Revision: https://reviews.llvm.org/D73220

[ARM,MVE] Revise immediate VBIC/VORR to look more like NEON.
Summary: In NEON, the immediate forms of VBIC and VORR are each
represented as a single MC instruction, which takes its immediate
operand already encoded in a NEON-friendly format: 8 data bits, plus
some control bits indicating how to expand them into a full vector.
In MVE, we represented immediate VBIC and VORR as four separate MC 
instructions each, for an 8-bit immediate shifted left by 0, 8, 16 or 24
bits. For each one, the value of the immediate operand is in the
'natural' form, i.e. the numerical value that would actually be BICed or
ORRed into each vector lane (and also the same value shown in assembly).
For example, MVE_VBICIZ16v4i32 takes an operand such as 0xab0000, which
NEON would represent as 0xab | (control bits << 8).
The MVE approach is superficially nice (it makes assembly input and 
output easy, and it's also nice if you're manually constructing 
immediate VBICs). But it turns out that it's better for isel if we make
the NEON and MVE instructions work the same, because the ARMISD::VBICIMM
and VORRIMM node types already encode their immediate into the NEON
format, so it's easier if we can just use it.
Also, this commit reduces the total amount of code rather than 
increasing it, which is surely an indication that it really is simpler 
to do it this way!
Reviewers: dmgreen, ostannard, miyuki, MarkMurrayARM
Reviewed By: dmgreen
Subscribers: kristof.beyls, hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73205

[ARM,MVE] Support immediate vbicq,vorrq,vmvnq intrinsics.
Summary: Immediate vmvnq is code-generated as a simple vector constant
in IR, and left to the backend to recognize that it can be created with
an MVE VMVN instruction. The predicated version is represented as a 
select between the input and the same constant, and I've added a 
Tablegen isel rule to turn that into a predicated VMVN. (That should be
better than the previous VMVN + VPSEL: it's the same number of 
instructions but now it can fold into an adjacent VPT block.)
The unpredicated forms of VBIC and VORR are done by enabling the same 
isel lowering as for NEON, recognizing appropriate immediates and 
rewriting them as ARMISD::VBICIMM / ARMISD::VORRIMM SDNodes, which I 
then instruction-select into the right MVE instructions (now that I've 
also reworked those instructions to use the same MC operand encoding). 
In order to do that, I had to promote the Tablegen SDNode instance
`NEONvorrImm` to a general `ARMvorrImm` available in MVE as well, and 
similarly for `NEONvbicImm`.
The predicated forms of VBIC and VORR are represented as a vector select
between the original input vector and the output of the unpredicated
operation. The main convenience of this is that it still lets me use the
existing isel lowering for VBICIMM/VORRIMM, and not have to write
another copy of the operand encoding translation code.
This intrinsic family is the first to use the `imm_simd` system I put 
into the MveEmitter tablegen backend. So, naturally, it showed up a bug
or two (emitting bogus range checks and the like). Fixed those, and
added a full set of tests for the permissible immediates in the existing
Sema test.
Also adjusted the isel pattern for `vmovlb.u8`, which stopped matching 
because lowering started turning its input into a VBICIMM. Now it 
recognizes the VBICIMM instead.
Reviewers: dmgreen, MarkMurrayARM, miyuki, ostannard
Reviewed By: dmgreen
Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D72934

[AArch64][SVE] Add first-faulting load intrinsic
Summary: Implements the llvm.aarch64.sve.ldff1 intrinsic and DAG combine
rules for first-faulting loads with sign & zero extends
Reviewers: sdesmalen, efriedma, andwar, dancgr, rengolin
Reviewed By: sdesmalen
Subscribers: tschuett, kristof.beyls, hiraditya, rkruppe, psnobl,
cameron.mcinally, cfe-commits, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73025

Treat C# `using` as a control statement
Contributed by jbcoe!
Summary: Unless SpaceBeforeParensOptions is set to SBPO_Never, a space
will be put between `using` and `(` in C# code.
Reviewers: klimek, MyDeveloperDay, krasimir
Reviewed By: krasimir
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D72144

[Alignement][NFC] Deprecate untyped CreateAlignedLoad
Summary: This is patch is part of a series to introduce an Alignment
type. See this thread for context:
http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this
patch for the introduction of the type: https://reviews.llvm.org/D64790
Reviewers: courbet
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, kerbowa, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D73260