[flang] Implement DOT_PRODUCT in the runtime

API, implementation, and basic tests for the transformational
reduction intrinsic function DOT_PRODUCT in the runtime support
library.

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

Modules: Simplify how DisableGeneratingGlobalModuleIndex is set, likely NFC

DisableGeneratingGlobalModuleIndex was being set by
CompilerInstance::findOrCompileModuleAndReadAST most of (but not all of)
the times it returned `nullptr` as a "normal" failure. Pull that up to
the caller, CompilerInstance::loadModule, to simplify the code. This
resolves a number of FIXMEs added during the refactoring in
5cca622310c10fdf6f921b6cce26f91d9f14c762.

The extra cases where this is set are all some version of a fatal error,
and the only client of the field, shouldBuildGlobalModuleIndex, seems
to be unreachable in that case. Even if there is some corner case where
this has an effect, it seems like the right/consistent behaviour.

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

Return "[CGCall] Annotate `this` argument with alignment"

The original change was reverted because it was discovered
that clang mishandles thunks, and they receive wrong
attributes for their this/return types - the ones for the function
they will call, not the ones they have.

While i have tried to fix this in https://reviews.llvm.org/D100388
that patch has been up and stuck for a month now,
with little signs of progress.

So while it will be good to solve this for real,
for now we can simply avoid introducing the bug,
by not annotating this/return for thunks.

This reverts commit 6270b3a1eafaba4279e021418c5a2c5a35abc002,
relanding 0aa0458f1429372038ca6a4edc7e94c96cd9a753.

[Clang][Codegen] Do not annotate thunk's this/return types with align/deref/nonnull attrs

As it was discovered in post-commit feedback
for 0aa0458f1429372038ca6a4edc7e94c96cd9a753,
we handle thunks incorrectly, and end up annotating
their this/return with attributes that are valid
for their callees, not for thunks themselves.

While it would be good to fix this properly,
and keep annotating them on thunks,
i've tried doing that in https://reviews.llvm.org/D100388
with little success, and the patch is stuck for a month now.

So for now, as a stopgap measure, subj.

[NFC][Clang][Codegen] Add tests with wrong attributes on this/return of thunks

From https://reviews.llvm.org/D100388

[ARM] Constrain CMPZ shift combine to a single use

We currently prefer t2CMPrs over t2CMPri when the node contains a shift.
This can introduce more nodes if the shift has multiple uses though, as
value from the shift will be needed anyway, and in the case of a t2CMPri
compared with zero will more readily be removed entirely.

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

[lldb] Fixup indirect symbols as they are signed.

This fixes a bunch of test failures in Apple Silicon (arm64e).

[lldb] Fixup more code addresses

The Swift async task pointers are signed on arm64e and we need to fixup
the addresses in the CFA and DWARF expressions.

Modules: Rename ModuleBuildFailed => DisableGeneratingGlobalModuleIndex, NFC

Rename CompilerInstance's ModuleBuildFailed field to
DisableGeneratingGlobalModuleIndex, which more precisely describes its
role. Otherwise, it's hard to suss out how it's different from
ModuleLoader::HadFatalFailure, and what sort of code simplifications are
safe.

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

[mlir][spirv] Define spv.ImageQuerySize operation

Support OpImageQuerySize in spirv dialect

co-authored-by: Alan Liu <alanliu.yf@gmail.com>

Reviewed By: antiagainst

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

[analyzer][solver] Prevent use of a null state

rdar://77686137

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

[pstl] Use logical operator for loop condition in tests

Fix a probable typo in two PSTL tests that causes warnings with GCC.

Patch by Jonathan Wakely (jwakely).

Reviewed By: zoecarver

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

Modules: Remove ModuleLoader::OtherUncachedFailure, NFC

5cca622310c10fdf6f921b6cce26f91d9f14c762 refactored
CompilerInstance::loadModule, splitting out
findOrCompileModuleAndReadAST, but was careful to avoid making any
functional changes. It added ModuleLoader::OtherUncachedFailure to
facilitate this and left behind FIXMEs asking why certain failures
weren't cached.

After a closer look, I think we can just remove this and simplify the
code. This changes the behaviour of the following (simplified) code from
CompilerInstance::loadModule, causing a failure to be cached more often:

```
  if (auto MaybeModule = MM.getCachedModuleLoad(*Path[0].first))
    return *MaybeModule;
  if (ModuleName == getLangOpts().CurrentModule)
    return MM.cacheModuleLoad(PP.lookupModule(...));
  ModuleLoadResult Result = findOrCompileModuleAndReadAST(...);
  if (Result.isNormal()) // This will be 'true' more often.
    return MM.cacheModuleLoad(..., Module);
  return Result;
```

`MM` here is a ModuleMap owned by the Preprocessor. Here are the cases
where `findOrCompileModuleAndReadAST` starts returning a "normal" failed
result:
- Emitted `diag::err_module_not_found`, where there's no module map
  found.
- Emitted `diag::err_module_build_disabled`, where implicitly building
  modules is disabled.
- Emitted `diag::err_module_cycle`, which detects module cycles in the
  implicit modules build system.
- Emitted `diag::err_module_not_built`, which avoids building a module
  in this CompilerInstance if another one tried and failed already.
- `compileModuleAndReadAST()` was called and failed to build.

The four errors are all fatal, and last item also reports a fatal error,
so it this extra caching has no functionality change... but even if it
did, it seems fine to cache these failed results within a ModuleMap
instance (note that each CompilerInstance has its own Preprocessor and
ModuleMap).

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

[libcxx][ranges] Fix `ranges::empty` when begin, end, and empty members are provided.

Before this commit, we'd get a compilation error because the operator() overload was ambiguous.

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

[PowerPC] Add clang option -m[no-]prefixed

Add user-facing front end option to turn off power10 prefixed instructions.

Reviewed By: nemanjai

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

[libomptarget][amdgpu] Fix truncation error for partial wavefront

[libomptarget][amdgpu] Fix truncation error for partial wavefront

The partial barrier implementation involves one wavefront resetting and N-1
waiting. This change future proofs against launching with a number of threads
that is not a multiple of the wavefront size.

Reviewed By: jdoerfert

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

[libomptarget][amdgpu] Convert an assert to print and offload_fail

[libomptarget][amdgpu] Convert an assert to print and offload_fail

The kernel launched is supposed to be present in the binary, but a not yet
diagnosed bug means it is missing for some of the qmcpack test cases. Changing
from assert to print and offload_fail should help diagnose that and similar bugs.

Reviewed By: jdoerfert

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

[mlir] Add python test for shape dialect

Add basic test for shape.const_shape op as start.

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

[InstSimplify] Remove redundant {insert,extract}_vector intrinsic chains

This commit removes some redundant {insert,extract}_vector intrinsic
chains by implementing the following patterns as instsimplifies:

   (insert_vector _, (extract_vector X, 0), 0) -> X
   (extract_vector (insert_vector _, X, 0), 0) -> X

Reviewed By: peterwaller-arm

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

[OpenMP] Test unified shared memory tests only on systems that support it.

Add a `REQUIRES: unified_shared_memory` option to tests that use `#pragma omp requires unified_shared_memory`.

For CUDA, the feature tag is derived from LIBOMPTARGET_DEP_CUDA_ARCH which itself is derived using [[ https://cmake.org/cmake/help/latest/module/FindCUDA.html#commands | cuda_select_nvcc_arch_flags ]]. The latter determines which compute capability the GPU in the system supports. To ensure that this is the CUDA arch being used, we could also set the `-Xopenmp-target -march=` flag.
In the absence of an NVIDIA GPU, LIBOMPTARGET_DEP_CUDA_ARCH will be 35. That is, in that case we are assuming unified_shared_memory is not available. CUDA plugin testing could be disabled entirely in this case, but this currently depends on `LIBOMPTARGET_CAN_LINK_LIBCUDA OR LIBOMPTARGET_FORCE_DLOPEN_LIBCUDA`, not on whether the hardware is actually available.

For all other targets, nothing changes and we are assuming unified shared memory is available. This might need refinement if not the case.

This tries to fix the [[ http://meinersbur.de:8011/#/builders/143 | OpenMP Offloading Buildbot ]] that, although brand-new, only has a Pascal-generation (sm_61) GPU installed. Hence, tests that require unified shared memory are currently failing. I wish I had known in advance.

Reviewed By: protze.joachim, tianshilei1992

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

[AMDGPU] Only allow global fp atomics with unsafe option

Previously we were allowing to use FP atomics without
-amdgpu-unsafe-fp-atomics option if a scope is less then
system. This is not safe just as well if we have UC memory.

This change only allows global and flat FP atomics with
the unsafe option. Consequentially that makes a check for
denorm mode redundant since we skip it with the unsafe
option and do not have a way to produce these instructions
without it anyway.

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

[HIP] Add __builtin_amdgcn_groupstaticsize

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

Parse vector bool when stdbool.h and altivec.h are included

Currently when including stdbool.h and altivec.h declaration of `vector bool` leads to
errors due to `bool` being expanded to '_Bool`. This patch allows the parser
to recognize `_Bool`.

Reviewed By: hubert.reinterpretcast, Everybody0523

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

[AArch64][SVE] Fix missed immediate selection due to mishandling of signedness

The complex selection pattern for add/sub shifted immediates is
incorrect in it's handling of incoming constant values, in that it
does not properly anticipate the values to be signed extended to
32-bits.

Co-authored-by: Graham Hunter <graham.hunter@arm.com>
Differential Revision: https://reviews.llvm.org/D101833

[mlir][linalg] Remove IndexedGenericOp support from FusionOnTensors...

after introducing the IndexedGenericOp to GenericOp canonicalization (https://reviews.llvm.org/D101612).

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

[mlir] Replace vector-to-scf with progressive-vector-to-scf

Depends On D102388

Reviewed By: nicolasvasilache

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

[mlir][linalg] Remove IndexedGenericOp support from DropUnitDims...

after introducing the IndexedGenericOp to GenericOp canonicalization (https://reviews.llvm.org/D101612).

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

[TableGen] Make the NUL character invalid in .td files

Now uses tr instead of sed.

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

Reapply [ConstantFold] Fold more operations to poison

This was reverted to mitigate mitigate miscompiles caused by
the logical and/or to bitwise and/or fold. Reapply it now that
the underlying issue has been fixed by D101191.

-----

This patch folds more operations to poison.

Alive2 proof: https://alive2.llvm.org/ce/z/mxcb9G (it does not contain tests about div/rem because they fold to poison when raising UB)

Reviewed By: nikic

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

[mlir] Migrate vector-to-loops.mlir to ProgressiveVectorToSCF

Create a copy of vector-to-loops.mlir and adapt the test for
ProgressiveVectorToSCF. Fix a small bug in getExtractOp() triggered by
this test.

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

Fix section title underlining in the release notes

Revert "[CMake][ELF] Add -fno-semantic-interposition and -Bsymbolic-functions"

This reverts commit 3bf1acab5b454ad7fb2074b34663108b53620695.

This is causing the test `gcov-shared-flush.c' to fail on the 2-stage
aarch64 buildbots (https://lab.llvm.org/buildbot/#/builders/7/builds/2720).

Add entry about Hexagon V68 support to the release notes

[AIX] XFAIL CodeGen/Generic/externally_available.ll

    Globals with “available_externally” linkage should never be emitted into the
    object file corresponding to the LLVM module.

    However, AIX system assembler default print error for undefined reference .
    so AIX chose to emit the available externally symbols into .s,
    so that users won't run into errors in situations like:

    clang -target powerpc-ibm-aix -xc -<<<$'extern inline
    __attribute__((__gnu_inline__)) void foo() {}\nvoid bar() { foo(); }' -O
    -Xclang -disable-llvm-passes

Reviewed By: hubert.reinterpretcast

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

[mlir] Do not use pass labels in unrolled ProgressiveVectorToSCF

Do not rely on pass labels to detect if the pattern was already applied in the past (which allows for more some extra optimizations to avoid extra InsertOps and ExtractOps). Instead, check if these optimizations can be applied on-the-fly.

This also fixes a bug, where vector.insert and vector.extract ops sometimes disappeared in the middle of the pass because they get folded away, but the next application of the pattern expected them to be there.

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

[gn build] (manually) port 92f9852fc99b, clang-repl

[clang-tidy] Fix test that requires Windows platofrm

This commit fixes the cppcoreguidelines-pro-type-vararg test when it
runs on a Windows host, but the toolchain is targeted a non-Windows
platform.

Reviewed By: njames93

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

[PowerPC] Handle inline assembly clobber of link regsiter

This patch adds the handling of clobbers of the link register LR for inline
assembly.

This patch is to fix:
https://bugs.llvm.org/show_bug.cgi?id=50147

Reviewed By: nemanjai, #powerpc

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

[VPlan] Adjust assert in splitBlock to allow splitting at end.

SplitAt should only be dereferenced in the assert if it does not point
to the end of the block. This fixes a crash in the added test case.

[X86] X86ExpandPseudo.cpp - try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef copies. NFCI.

[X86] X86InstrInfo.cpp - try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef copies. NFCI.

[X86] VZeroUpperInserter::insertVZeroUpper - avoid DebugLoc creation by embedding in the BuildMI calls. NFCI.

Try to pass DebugLoc by const-ref to avoid costly TrackingMDNodeRef copies.

[Passes] Use regex to match GlobalsAA line in test.

On some platforms/compiler combinations, it appears the output is
slightly different. Update the test to use a regex, as is done at other
places in the new-pm-*default.ll tests to address buildbot failures.

[Passes] Run GlobalsAA before LICM during LTO in new PM.

This patch adjusts the LTO pipeline in the new PM to run GlobalsAA
before LICM to match the legacy PM.

This fixes a regression where the new PM failed to vectorize loops that
require hoisting/sinking by LICM depending on GlobalsAA info.

Reviewed By: aeubanks

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

[RISCV][NFC] Simplify test run lines

Several tests had -verify-machineinstrs twice, and several tests were
explicitly specifying the default FileCheck prefix of CHECK.

[Passes] Use MemorySSA for LICM during LTO.

Split off from D102345 to commit this separately from other changes in
the patch. This aligns the behavior of the new PM with the legacy PM
for LTO, with respect to running LICM.

Together with the remaining changes in D102345, this fixes new PM
regressions where we fail to vectorize loops that are vectorized with
the legacy PM.

[clang-repl] Fix ClangReplInterpreterTests unittest dependency.

[Utils] Use whoami to get username for arcanist warning message

959eec1fddc83c90c208789f20cb6573b2a20642 changed the message
to show the local username with "$user" but this is not always set.

Some systems will have USER/USERNAME/LOGNAME, so just use "whoami"
instead.

[PowerPC] Provide doubleword vector predicate form comparisons on Power7

There are two reasons this shouldn't be restricted to Power8 and up:
1. For XL compatibility
2. Because clang will expand comparison operators to these intrinsics*

*Without this patch, the following causes a selection error:

int test(vector signed long a, vector signed long b) {
  return a < b;
}

This patch provides the handling for the intrinsics in the back
end and removes the Power8 guards from the predicate functions
(vec_{all|any}_{eq|ne|gt|ge|lt|le}).

[SCEV] Apply guards to max with non-unitary steps.

We already apply loop-guards when computing the maximum with unitary
steps. This extends the code to also do so when dealing with non-unitary
steps.

This allows us to infer a tighter maximum in some cases.

Reviewed By: nikic

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

[TSAN] Honor failure memory orders in AtomicCAS

LLVM has lifted strong requirements for CAS failure memory orders in 431e3138a and 819e0d105e84.

Add support for honoring them in `AtomicCAS`.

https://github.com/google/sanitizers/issues/970

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

[clang-repl] Add final set of missing library dependencies.

[libcxx] NFC. Fix misprint unodered -> unordered

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

[NFC] Add GetInferiorAddrSize method, unify code to compute

MachProcess.mm has a sequence to get the address size in
the inferior in three places; and I'm about to add a fourth
in a future patch.  Not a fan.

Revert "[SimpleLoopUnswitch] Port partially invariant unswitch from LoopUnswitch to SimpleLoopUnswitch"

This reverts commit 88b259c01463c08ac2575b4432c07ea7751946b5.

It needs to fix below bugs.

https://bugs.llvm.org/show_bug.cgi?id=50279
https://bugs.llvm.org/show_bug.cgi?id=50302

[FPEnv][X86] Implement lowering of llvm.set.rounding

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

Use an allow list on reserved macro identifiers

The allow list is based on various official sources (see in-code comment).

This fixes https://bugs.llvm.org/show_bug.cgi?id=50248

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

[clang-repl] Add exhaustive list of libInterpreter dependencies.

This patch should appease the bots building with -DBUILD_SHARED_LIBS=On,
resolving the regression introduced in 92f9852fc99b.

[clang-repl] Recommit "Land initial infrastructure for incremental parsing"

Original commit message:

  In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
  mentioned our plans to make some of the incremental compilation facilities
  available in llvm mainline.

  This patch proposes a minimal version of a repl, clang-repl, which enables
  interpreter-like interaction for C++. For instance:

  ./bin/clang-repl
  clang-repl> int i = 42;
  clang-repl> extern "C" int printf(const char*,...);
  clang-repl> auto r1 = printf("i=%d\n", i);
  i=42
  clang-repl> quit

  The patch allows very limited functionality, for example, it crashes on invalid
  C++. The design of the proposed patch follows closely the design of cling. The
  idea is to gather feedback and gradually evolve both clang-repl and cling to
  what the community agrees upon.

  The IncrementalParser class is responsible for driving the clang parser and
  codegen and allows the compiler infrastructure to process more than one input.
  Every input adds to the “ever-growing” translation unit. That model is enabled
  by an IncrementalAction which prevents teardown when HandleTranslationUnit.

  The IncrementalExecutor class hides some of the underlying implementation
  details of the concrete JIT infrastructure. It exposes the minimal set of
  functionality required by our incremental compiler/interpreter.

  The Transaction class keeps track of the AST and the LLVM IR for each
  incremental input. That tracking information will be later used to implement
  error recovery.

  The Interpreter class orchestrates the IncrementalParser and the
  IncrementalExecutor to model interpreter-like behavior. It provides the public
  API which can be used (in future) when using the interpreter library.

  Differential revision: https://reviews.llvm.org/D96033

[mlir] Support masks in TransferOpReduceRank and TransferReadPermutationLowering

These two patterns allow for more efficient codegen in VectorToSCF.

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

[gn build] Port d8b37de8a478

[GC][NFC] Move GCStrategy from CodeGen to IR

We want it to be available in analyzes so that we could use the
CodeGen notion in middle-end passes (for example, to check if
a GC may free some particular pointer).

This is a preparatory patch that simply moves the files around.

Note: if this causes some build issues, this patch must just be reverted.

Differential Revision: https://reviews.llvm.org/D100557
Reviewed By: reames

[JITLink] Expose x86-64 pointer jump stub block construction.

This can be useful for clients who want to define their own symbol for the
stub, or re-use some existing symbol.

[JITLink] Add a transferDefinedSymbol operation.

The transferDefinedSymbol operation updates a Symbol's target block, offset,
and size. This can be convenient when you want to redefine the content of some
symbol(s) pointing at a block, while retaining the original block in the graph.

Add some warnings when debugserver is running in translation

A debugserver launched x86_64 cannot control an arm64/arm64e
process on an Apple Silicon system.  Warn when this situation
has happened and return an error for the most common case of
attach.  I think there will be refinements to this in the
future, but start out by making it easy to spot the problem
when it happens.

rdar://76630595

[Coroutines] Salvege Debug.values

Summary: The previous implementation of coro-split didn't collect values
used by dbg instructions into the spills which made a log debug info
unavailable with optimization on.
This patch tries to collect these uses which are used by dbg.values. In
this way, the debugbility of coroutine could be as powerful as normal
functions with optimization on.

To avoid enlarging the coroutine frame, this patch only collects
`dbg.value` whose value is already in the coroutine frame. This decision
may make some debug info getting unavailable. But if we are with
optimization on, the performance issue should be considered first. And
this patch would make the debugbility of coroutine to be better only
without changing the layout of the frame.

Test-plan: check-llvm

Reviewed By: aprantl, lxfind

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

[mlir][tosa] Fix tosa.cast semantics to perform rounding/clipping

Rounding to integers requires rounding (for floating points) and clipping
to the min/max values of the destination range. Added this behavior and
updated tests appropriately.

Reviewed By: sjarus, silvas

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

Revert "[clang-repl] Land initial infrastructure for incremental parsing"

This reverts commit 44a4000181e1a25027e87f2ae4e71cb876a7a275.

We are seeing build failures due to missing dependency to libSupport and
CMake Error at tools/clang/tools/clang-repl/cmake_install.cmake
file INSTALL cannot find

[Coroutines] Enable printing coroutine frame when dbg info is available

Summary: This patch tries to build debug info for coroutine frame in the
middle end. Although the coroutine frame is constructed and maintained by
the compiler and the programmer shouldn't care about the coroutine frame
by the design of C++20 coroutine,
a lot of programmers told me that they want to see the layout of the
coroutine frame strongly. Although C++ is designed as an abstract layer
so that the programmers shouldn't care about the actual memory in bits,
many experienced C++ programmers  are familiar with assembler and
debugger to see the memory layout in fact, After I was been told they
want to see the coroutine frame about 3 times, I think it is an actual
and desired demand.

However, the debug information is constructed in the front end and
coroutine frame is constructed in the middle end. This is a natural and
clear gap. So I could only try to construct the debug information in the
middle end after coroutine frame constructed. It is unusual, but we are
in consensus that the approch is the best one.

One hard part is we need construct the name for variables since there
isn't a map from llvm variables to DIVar. Then here is the strategy this
patch uses:
- The name `__resume_fn `, `__destroy_fn` and `__coro_index ` are
  constructed by the patch.
- Then the name `__promise` comes from the dbg.variable of corresponding
  dbg.declare of PromiseAlloca, which shows highest priority to
construct the debug information for the member of coroutine frame.
- Then if the member is struct, we would try to get the name of the llvm
  struct directly. Then replace ':' and '.' with '_' to make it
printable for debugger.
- If the member is a basic type like integer or double, we would try to
  emit the corresponding name.
- Then if the member is a Pointer Type, we would add `Ptr` after
  corresponding pointee type.
- Otherwise, we would name it with 'UnknownType'.

Reviewered by: lxfind, aprantl, rjmcall, dblaikie

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

[SLP] Add insertelement instructions to vectorizable tree

Add new type of tree node for `InsertElementInst` chain forming vector.
These instructions could be either removed, or replaced by shuffles during
vectorization and we can add this node to cost model, so naturally estimating
their cost, getting rid of `CompensateCost` tricks and reducing further work
for InstCombine. This fixes PR40522 and PR35732 in a natural way. Also this
patch is the first step towards revectorization of partially vectorization
(to fix PR42022 completely). After adding inserts to tree the next step is
to add vector instructions there (for instance, to merge `store <2 x float>`
and `store <2 x float>` to `store <4 x float>`).

Fixes PR40522 and PR35732.

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

[SLP][Test] Fix and precommit tests for D98714

[SLP][Test] Fix and precommit tests for D98714

[clang-repl] Land initial infrastructure for incremental parsing

In http://lists.llvm.org/pipermail/llvm-dev/2020-July/143257.html we have
mentioned our plans to make some of the incremental compilation facilities
available in llvm mainline.

This patch proposes a minimal version of a repl, clang-repl, which enables
interpreter-like interaction for C++. For instance:

./bin/clang-repl
clang-repl> int i = 42;
clang-repl> extern "C" int printf(const char*,...);
clang-repl> auto r1 = printf("i=%d\n", i);
i=42
clang-repl> quit

The patch allows very limited functionality, for example, it crashes on invalid
C++. The design of the proposed patch follows closely the design of cling. The
idea is to gather feedback and gradually evolve both clang-repl and cling to
what the community agrees upon.

The IncrementalParser class is responsible for driving the clang parser and
codegen and allows the compiler infrastructure to process more than one input.
Every input adds to the “ever-growing” translation unit. That model is enabled
by an IncrementalAction which prevents teardown when HandleTranslationUnit.

The IncrementalExecutor class hides some of the underlying implementation
details of the concrete JIT infrastructure. It exposes the minimal set of
functionality required by our incremental compiler/interpreter.

The Transaction class keeps track of the AST and the LLVM IR for each
incremental input. That tracking information will be later used to implement
error recovery.

The Interpreter class orchestrates the IncrementalParser and the
IncrementalExecutor to model interpreter-like behavior. It provides the public
API which can be used (in future) when using the interpreter library.

Differential revision: https://reviews.llvm.org/D96033

[mlir] Support memref layout maps in vector transfer ops

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

[mlir] Unrolled progressive-vector-to-scf.

Instead of an SCF for loop, these pattern generate fully unrolled loops with no temporary buffer allocations.

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

[mlir] Allow empty position in vector.insert and vector.extract

Such ops are no-ops and are folded to their respective `source`/`vector` operand.

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

[mlir] Fix masked vector transfer ops with broadcasts

Broadcast dimensions of a vector transfer op have no corresponding dimension in the mask vector. E.g., a 2-D TransferReadOp, where one dimension is a broadcast, can have a 1-D `mask` attribute.

This commit also adds a few additional transfer op integration tests for various combinations of broadcasts, masking, dim transposes, etc.

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

[Debug-Info] add -gstrict-dwarf support in backend

Reviewed By: dblaikie, probinson

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

Revert "[mlir] Fix masked vector transfer ops with broadcasts"

This reverts commit c9087788f7e41285445729127dd07ff7f82e3fc0.

Accidentally pushed old version of the commit.

[mlir] Fix masked vector transfer ops with broadcasts

Broadcast dimensions of a vector transfer op have no corresponding dimension in the mask vector. E.g., a 2-D TransferReadOp, where one dimension is a broadcast, can have a 1-D `mask` attribute.

This commit also adds a few additional transfer op integration tests for various combinations of broadcasts, masking, dim transposes, etc.

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

[clang] Minor fix for MarkVarDeclODRUsed

Merge two if as follow up of https://reviews.llvm.org/D102270

Rename human-readable name for DW_LANG_Mips_Assembler

The Mips in DW_LANG_Mips_Assembler is a vendor name not an
architecture name and in lack of a proper generic DW_LANG_assembler,
some assemblers emit DWARF using this tag. Due to a warning I recently
introduced users will now be greeted with

  This version of LLDB has no plugin for the mipsassem language. Inspection of frame variables will be limited.

By renaming this to just "Assembler" this error message will make more sense.

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

rdar://77214764

Handle unexpanded packs appearing in type-constraints.

For a type-constraint in a lambda signature, this makes the lambda
contain an unexpanded pack; for requirements in a requires-expressions
it makes the requires-expression contain an unexpanded pack; otherwise
it's invalid.

PR50306: When instantiating a generic lambda with a constrained 'auto',
properly track that it has constraints.

Previously an instantiation of a constrained generic lambda would behave
as if unconstrained because we incorrectly cached a "has no constraints"
value that we computed before the constraints from 'auto' parameters
were attached.

Clean up handling of constrained parameters in lambdas.

No functionality change intended.

Add test for substitutability of variable templates in closure type
mangling.

[AMDGPU][OpenMP] Emit textual IR for -emit-llvm -S

Previously clang would print a binary blob into the bundled file
for amdgcn. With this patch, it will instead print textual IR as
expected.

Reviewed By: JonChesterfield, ronlieb

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

Change-Id: I10c0127ab7357787769fdf9a2edd4b3071e790a1

scudo: Require fault address to be in bounds for UAF.

The bounds check that we previously had here was suitable for secondary
allocations but not for UAF on primary allocations, where it is likely
to result in false positives. Fix it by using a different bounds check
for UAF that requires the fault address to be in bounds.

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

[libcxx] modifies `_CmpUnspecifiedParam` ignore types outside its domain

D85051's honeypot solution was a bit too aggressive swallowed up the
comparison types, which made comparing objects of different ordering
types ambiguous.

Depends on D101707.

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

[mlir][sparse][capi][python] add sparse tensor passes

First set of "boilerplate" to get sparse tensor
passes available through CAPI and Python.

Reviewed By: stellaraccident

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

[AMDGPU] Refactor shouldExpandAtomicRMWInIR(). NFC.

This is logic simplification for better readability.

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

[mlir][Linalg] Add interface methods to get lhs and rhs of contraction

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

Change the context instruction for computeKnownBits in LoadStoreVectorizer pass

This change enables cases for which the index value for the first
load/store instruction in a pair could be a function argument. This
allows using llvm.assume to provide known bits information in such
cases.

Patch by Viacheslav Nikolaev. Thanks!

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

Optimize GSymCreator::finalize.

The algorithm removing duplicates from the Funcs list used to have
amortized quadratic time complexity because it was potentially
removing each entry using std::vector::erase individually. This
patch is now using a erase-remove idiom with an adapted
removeIfBinary algorithm.

Probably this was made under the assumption that these removals are
rare, but there are cases where the case of duplicate entries is
occurring frequently. In these cases, the actual runtime was very
poor, taking hours to process a single binary of around 1 GiB size
including debug info. Another factor contributing to that is the
frequent output of the warning, which is now removed.

It seems this is particularly an issue with GCC-compiled binaries,
rather than clang-built binaries.

Reviewed By: clayborg

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

[mlir] Fix ssa values naming bug

Address comments in https://reviews.llvm.org/D102226 to fix the bug + style violations

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

[lld][WebAssembly] Allow data symbols to extend past end of segment

This fixes a bug with string merging with string symbols that contain
NULLs, as is the case in the `merge-string.s` test.

The bug only showed when we run with `--relocatable` and then try read
the resulting object back in.  In this case we would end up with string
symbols that extend past the end of the segment in which they live.

The problem comes from the fact that sections which are flagged as
string mergable assume that all strings are NULL terminated.  The
merging algorithm will drop trailing chars that follow a NULL since they
are essentially unreachable.  However, the "size" attribute (in the
symbol table) of such a truncated symbol is not updated resulting a
symbol size that can overlap the end of the segment.

I verified that this can happen in ELF too given the right conditions
and the its harmless enough.  In practice Strings that contain embedded
null should not be part of a mergable section.

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

[WebAssembly] Add TLS data segment flag: WASM_SEG_FLAG_TLS

Previously the linker was relying solely on the name of the segment
to imply TLS.

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

[WebAssembly] Allow Wasm EH with Emscripten SjLj

We explicitly made it error out in D101403, out of a good intention that
the error message will make people less confusing. Turns out, we weren't
failing all cases of wasm EH + SjLj; only a few cases were failing and
our client was able to get around by fixing source code, but now we made
it fail for all cases, even the cases that previously succeeded fail,
which we didn't intend. This reverts that change.

Reviewed By: tlively

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

[RISCV] Remove RISCVII:VSEW enum. Make encodeVYPE operate directly on SEW.

The VSEW encoding isn't a useful value to pass around. It's better
to use SEW or log2(SEW) directly. The only real ugliness is that
the vsetvli IR intrinsics use the VSEW encoding, but it's easy
enough to decode that when the intrinsic is processed.

Fix bad mangling of <data-member-prefix> for a closure in the initializer of a variable at global namespace scope.

This implements the direction proposed in
https://github.com/itanium-cxx-abi/cxx-abi/pull/126.

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