[clang-repl][CUDA] Re-land: Initial interactive CUDA support for clang-repl

CUDA support can be enabled in clang-repl with --cuda flag.
Device code linking is not yet supported. inline must be used with all
__device__ functions.

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

[mlir][bazel] Port for 660f714e26999d266232a1fbb02712bb879bd34e, second
attempt.

[mlir][bazel] Port for 660f714e26999d266232a1fbb02712bb879bd34e

[Clang][BFloat16] Upgrade __bf16 to arithmetic type, change mangling, and extend excess precision support

Pursuant to discussions at
https://discourse.llvm.org/t/rfc-c-23-p1467r9-extended-floating-point-types-and-standard-names/70033/22,
this commit enhances the handling of the __bf16 type in Clang.
- Firstly, it upgrades __bf16 from a storage-only type to an arithmetic
  type.
- Secondly, it changes the mangling of __bf16 to DF16b on all
  architectures except ARM. This change has been made in
  accordance with the finalization of the mangling for the
  std::bfloat16_t type, as discussed at
  https://github.com/itanium-cxx-abi/cxx-abi/pull/147.
- Finally, this commit extends the existing excess precision support to
  the __bf16 type. This applies to hardware architectures that do not
  natively support bfloat16 arithmetic.
Appropriate tests have been added to verify the effects of these
changes and ensure no regressions in other areas of the compiler.

Reviewed By: rjmccall, pengfei, zahiraam

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

[CodeGen] Remove unused MachineMemOperand::Profile (NFC)

The last use was removed by
commit 48b185d6f718f0408a54bc7be8387beb3237cff3
Author: Dan Gohman <gohman@apple.com>
Date:   Fri Sep 25 20:36:54 2009 +0000

[Sema] Remove unused declaration startLambdaDefinition

The corresponding function definition was removed by:

  commit 93d7002dc4644b0a6f15a998dff0d55c72012e87
  Author: Corentin Jabot <corentinjabot@gmail.com>
  Date:   Sun Feb 6 22:58:43 2022 +0100

[clangd] Remove unused declaration onCallHierarchyOutgoingCalls

The corresponding function definition was removed by:

  commit 1a929525e86a20d0b3455a400d0dbed40b325a13
  Author: Kadir Cetinkaya <kadircet@google.com>
  Date:   Tue Dec 21 17:06:40 2021 +0100

[CodeGen] Remove unused declarations emitNonSPMDParallelCall and emitSPMDParallelCall

The corresponding function definitions were removed by:

  commit a2dbfb6b72db19ed851464160ef7539b50d43894
  Author: Giorgis Georgakoudis <georgakoudis1@llnl.gov>
  Date:   Wed Apr 21 11:41:31 2021 -0700

[AST] Remove unused declaration enumerateVFPtrs

The corresponding function definition was removed by:

  commit 9c6e9e313d61284f3d7fa46c86b6f999c8a1adea
  Author: Reid Kleckner <reid@kleckner.net>
  Date:   Thu Feb 27 19:40:09 2014 +0000

[Sema] Remove unused declaration ConvertIntegerToTypeWarnOnOverflow

The corresponding function definition was removed by:

  commit 077d083b4dd12538fc824d5784d455da0d86a1ea
  Author: Richard Smith <richard-llvm@metafoo.co.uk>
  Date:   Mon Aug 4 00:40:48 2014 +0000

[Driver] Remove redundant -z special case. NFC

[hwasan] support hwasan-match-all-tag flag for hwasan meminstrinsic calls

This patch implements `__hwasan_memset_match_all`, `__hwasan_memcpy_match_all` and `__hwasan_memmove_match_all`, making hwasan-match-all-tag flag working for hwasan versions of memset, memcpy and memmove.

Reviewed By: vitalybuka

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

[hwasan] support hwasan-match-all-tag flag for callback memory access instrumentation

Currently, hwasan-match-all-tag flag is supported in inline memory access instrumentation and outline memory access instrumentation, but not supported in callback memory access instrumentation.

- For inline memory access instrumentation: a hwasan-match-all-tag check is added following the tag-mismtach check, if tag from pointer is mismatched with tag from shadow memory and tag from pointer is not equal with hwasan-match-all-tag, then a tag-mismatch will be report.
- For outline memory acess instrumentation: MatchAllTag is encoded in AccessInfo, when emit HWASAN memaccess symbols, asm-printer emits assembly instructions to check if tag from pointer is equal with hwasan-match-all-tag.
- For callback memory access instrumentation: hwasan-match-all-tag check is not implemented in `__hwasan_load`/`__hwasan_store`.

This patch implements a set of callback functions: `__hwasan_[load|store][1|2|4|8|16|n]_match_all` and `__hwasan_load[load|store][1|2|4|8|16|n]_match_all_noabort`, making hwasan-match-all-tag flag working for callback memory access instrumentation.

Reviewed By: vitalybuka

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

[Driver][test] Replace legacy -target with --target=

[mlir] Fix non-const lvalue reference to type 'uint64_t' cannot bind to type 'size_t' error (NFC)

/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1007:39: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
    if (failed(propReader.parseVarInt(count)))
                                      ^~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:191:39: note: passing argument to parameter 'result' here
  LogicalResult parseVarInt(uint64_t &result) {
                                      ^
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:1020:44: error: non-const lvalue reference to type 'uint64_t' (aka 'unsigned long long') cannot bind to a value of unrelated type 'size_t' (aka 'unsigned long')
      if (failed(offsetsReader.parseVarInt(dataSize)) ||
                                           ^~~~~~~~
/Users/jiefu/llvm-project/mlir/lib/Bytecode/Reader/BytecodeReader.cpp:191:39: note: passing argument to parameter 'result' here
  LogicalResult parseVarInt(uint64_t &result) {
                                      ^
2 errors generated.

[CodeGen][NFC] Declare copy constructor & copy assignment as deleted for ScheduleDAG

ScheduleDAG has derived classes ScheduleDAGVLIW and ScheduleDAGRRList,
which own resources that are freed in their destructors. Static analyzer
warns b/c they do not have user-written copy constructors.

According to the design of ScheduleDAG, it seems that it should always
be passed by reference. So I declare them as deleted in this patch.

Reviewed By: RKSimon

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

[MLIR] Add native Bytecode support for properties

This is adding a new interface (`BytecodeOpInterface`) to allow operations to
opt-in skipping conversion to attribute and serializing properties to native
bytecode.

The scheme relies on a new section where properties are stored in sequence

  { size, serialize_properties }, ...

The operations are storing the index of a properties, a table of offset is
built when loading the properties section the first time.

This is a re-commit of 837d1ce0dc which conflicted with another patch upgrading
the bytecode and the collision wasn't properly resolved before.

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

[MemProf] Clean up MemProf instrumentation pass invocation

First, removes the invocation of the memprof instrumentation passes from
the end of the module simplification pass builder, where it doesn't
really belong. However, it turns out that this was never being invoked,
as it is guarded by an internal option not used anywhere (even tests).

These passes are actually added via clang under the -fmemory-profile
option. Changed this to add via the EP callback interface, similar to
the sanitizer passes. They are added to the EP for the end of the
optimization pipeline, which is roughly where they were being added
already (end of the pre-LTO link pipelines and non-LTO optimization
pipeline).

Ideally we should plumb the output file through to LLVM and set it up
there, so I have added a TODO.

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

[Vectorize] Fix warnings

This patch fixes:

  llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp:140:20: error:
  unused function 'operator<<' [-Werror,-Wunused-function]

  llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp:176:6: error:
  unused function 'dumpChain' [-Werror,-Wunused-function]

[Vectorize] Fix a warning

This patch fixes:

  llvm/lib/Transforms/Vectorize/LoadStoreVectorizer.cpp:1429:23:
  error: comparison of integers of different signs: 'int' and 'const
  size_t' (aka 'const unsigned long') [-Werror,-Wsign-compare]

[mlir][spirv][NFC] Clean up SPIR-V canonicalization

Follow best practices. Use llvm helper functions for readability.

Reviewed By: antiagainst

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

[RISCV] Add isel patterns to form tail undisturbed vfwadd.wv from fpextend_vl+vfwadd_vl+vp_merge.

We use a special TIED instructions for vfwadd.wv to avoid an
earlyclobber constraint preventing the first source and the destination
from being the same register.

This prevents our normal post process for forming TU instructions.
Add manual isel pattern instead. This matches what we do for FMA
for example.

skip test run on amdgcn-amd-amdhsa

[mlir][spirv] Enhance folding capability of spirv::CompositeExtractOp::fold

This PR improves the `spirv::CompositeExtractOp::fold` function by adding a backtracking mechanism.
The updated function can now traverse a chain of `CompositeInsertOp`s to find a match.

Patch By: nbpatel
Reviewed By: kuhar

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

Fix -Wsign-compare from D149893.

Fix runtime crash inside __kmpc_init_allocator

It seems load of traits.addr should be passed in runtime call.  Currently
the load of load traits.addr gets passed cause runtime to fail.

To fix this, skip the call to EmitLoadOfScalar for extra load.

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

[Dexter] XFAIL Dexter tests for Apple Silicon (arm64)

Revert "[lldb] Disable variable watchpoints when going out of scope"

Reverting https://reviews.llvm.org/D151366 until Ismail has a chance
to look at the ubuntu CI test failures and can reland.

This reverts commit 7c847ac4bd1bd8a89c7fbb4581328fa8cb0498f1.

Fix test failure after 2be0abb7fe7 (caused by bad merge, sorry).

[clang][modules] NFCI: Use `DirectoryEntryRef` for umbrella directory

This removes some deprecated uses of `DirectoryEntry::getName()`.

Depends on D151581.

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

[Driver] Reject AIX-specific link options on non-AIX targets

Follow-up to D106688 and D146431.

-b leads to a -Wunused-command-line-argument warning instead of an error
without linking phase.
-mxcoff-build-id= leads to a -Wunused-command-line-argument warning instead of
an error.

Rewrite load-store-vectorizer.

The motivation for this change is a workload generated by the XLA compiler
targeting nvidia GPUs.

This kernel has a few hundred i8 loads and stores.  Merging is critical for
performance.

The current LSV doesn't merge these well because it only considers instructions
within a block of 64 loads+stores.  This limit is necessary to contain the
O(n^2) behavior of the pass.  I'm hesitant to increase the limit, because this
pass is already one of the slowest parts of compiling an XLA program.

So we rewrite basically the whole thing to use a new algorithm.  Before, we
compared every load/store to every other to see if they're consecutive.  The
insight (from tra@) is that this is redundant.  If we know the offset from PtrA
to PtrB, then we don't need to compare PtrC to both of them in order to tell
whether C may be adjacent to A or B.

So that's what we do.  When scanning a basic block, we maintain a list of
chains, where we know the offset from every element in the chain to the first
element in the chain.  Each instruction gets compared only to the leaders of
all the chains.

In the worst case, this is still O(n^2), because all chains might be of length
1.  To prevent compile time blowup, we only consider the 64 most recently used
chains.  Thus we do no more comparisons than before, but we have the potential
to make much longer chains.

This rewrite affects many tests.  The changes to tests fall into two
categories.

1. The old code had what appears to be a bug when deciding whether a misaligned
   vectorized load is fast.  Suppose TTI reports that load <i32 x 4> align 4
   has relative speed 1, and suppose that load i32 align 4 has relative speed
   32.

   The intent of the code seems to be that we prefer the scalar load, because
   it's faster.  But the old code would choose the vectorized load.
   accessIsMisaligned would set RelativeSpeed to 0 for the scalar load (and not
   even call into TTI to get the relative speed), because the scalar load is
   aligned.

   After this patch, we will prefer the scalar load if it's faster.

2. This patch changes the logic for how we vectorize.  Usually this results in
   vectorizing more.

Explanation of changes to tests:

 - AMDGPU/adjust-alloca-alignment.ll: #1
 - AMDGPU/flat_atomic.ll: #2, we vectorize more.
 - AMDGPU/int_sideeffect.ll: #2, there are two possible locations for the call to @foo, and the pass is brittle to this.  Before, we'd vectorize in case 1 and not case 2.  Now we vectorize in case 2 and not case 1.  So we just move the call.
 - AMDGPU/adjust-alloca-alignment.ll: #2, we vectorize more
 - AMDGPU/insertion-point.ll: #2 we vectorize more
 - AMDGPU/merge-stores-private.ll: #1 (undoes changes from git rev 86f9117d476, which appear to have hit the bug from #1)
 - AMDGPU/multiple_tails.ll: #1
 - AMDGPU/vect-ptr-ptr-size-mismatch.ll: Fix alignment (I think related to #1 above).
 - AMDGPU CodeGen: I have difficulty commenting on these changes, but many of them look like #2, we vectorize more.
 - NVPTX/4x2xhalf.ll: Fix alignment (I think related to #1 above).
 - NVPTX/vectorize_i8.ll: We don't generate <3 x i8> vectors on NVPTX because they're not legal (and eventually get split)
 - X86/correct-order.ll: #2, we vectorize more, probably because of changes to the chain-splitting logic.
 - X86/subchain-interleaved.ll: #2, we vectorize more
 - X86/vector-scalar.ll: #2, we can now vectorize scalar float + <1 x float>
 - X86/vectorize-i8-nested-add-inseltpoison.ll: Deleted the nuw test because it was nonsensical.  It was doing `add nuw %v0, -1`, but this is equivalent to `add nuw %v0, 0xffff'ffff`, which is equivalent to asserting that %v0 == 0.
 - X86/vectorize-i8-nested-add.ll: Same as nested-add-inseltpoison.ll

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

[clang][modules] NFCI: Distinguish as-written and effective umbrella directories

For modules with umbrellas, we track how they were written in the module map. Unfortunately, the getter for the umbrella directory conflates the "as written" directory and the "effective" directory (either the written one or the parent of the written umbrella header).

This patch makes the distinction between "as written" and "effective" umbrella directories clearer. No functional change intended.

Reviewed By: benlangmuir

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

[Dexter] Don't hardcode x86_64 as the default architecture

Use platform.machine() as the default architecture instead of hardcoding
it to x86_64.

[llvm-debuginfod][NFC] Switch to OptTable

Reviewed By: mysterymath

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

[HWASan] use hwasan linker for Android 14+

This will allow to compile binaries that use hwasan to run on a
non-HWASan system image.

Reviewed By: pcc

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

[clang-tidy] Check for specific return types on all functions

Extend the check to all functions with return types like
         std::error_code, std::expected, boost::system::error_code, abseil::Status...

         Resolves issue https://github.com/llvm/llvm-project/issues/62884

Reviewed By: PiotrZSL

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

[mlir] Use std::optional instead of llvm::Optional (NFC)

This is part of an effort to migrate from llvm::Optional to std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

Revert "Factor out xcrun into a function (NFC)"

This reverts commit 97ca34996dbe5a61e79d7c559af7b15dc39c08a5.

Revert "Make function static (NFC)"

This reverts commit cefd2802aa49274942da87edf5019b5a23315f01.

[lldb] Skip instead of XFAIL TestInteractiveScriptedProcess

The test is failing on x86_64 but passing on arm64. Skip until Ismail
can investigate this further.

Make function static (NFC)

Factor out xcrun into a function (NFC)

[PseudoProbe] Do not force the calliste debug loc to inlined probes from __nodebug__ functions.

For pseudo probes we would like to keep their original dwarf discriminator (either a zero or null) until the first FS-discriminator pass. The inliner is a violation of that, given that it assigns inlinee instructions with no debug info with the that of the callsite. This is being disabled in this patch.

Reviewed By: wenlei

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

[PhaseOrdering] Add test for loop over span with hardened libc++.

Add a slightly reduced test case for a loop iterating over a std::span
with libc++ hardening.

See https://godbolt.org/z/cKerYq9fY.

[MLIR][python bindings] Fix inferReturnTypes + AttrSizedOperandSegments for optional operands

Right now `inferTypeOpInterface.inferReturnTypes` fails because there's a cast in there to `py::sequence` which throws a `TypeError` when it tries to cast the `None`s. Note `None`s are inserted into `operands` for omitted operands passed to the generated builder:

```
    operands.append(_get_op_result_or_value(start) if start is not None else None)
    operands.append(_get_op_result_or_value(stop) if stop is not None else None)
    operands.append(_get_op_result_or_value(step) if step is not None else None)
```

Note also that skipping appending to the list operands doesn't work either because [[ https://github.com/llvm/llvm-project/blob/27c37327da67020f938aabf0f6405f57d688441e/mlir/lib/Bindings/Python/IRCore.cpp#L1585 | build generic ]] checks against the number of operand segments expected.

Currently the only way around is to handroll through `ir.Operation.create`.

Reviewed By: rkayaith

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

[libc++][NFC] Add additional test case for modules issue in Objective-C++

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

[SLP]Fix getSpillCost functions.

There are several issues in the current implementation. The instructions
are not properly ordered, if they are placed in different basic blocks,
need to reverse the order of blocks. Also, need to exclude
non-vectorizable nodes and check for CallBase, not CallInst, otherwise
invoke calls are not handled correctly.

[RISCV] Simplify code in LowerIS_FPCLASS. NFC

[RISCV] Remove extra MVT::Other result from creation of RISCVISD::FCLASS_VL.

Add fastmath attributes to llvm.call_intrinsic

Reviewed By: Mogball

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

[RISCV] Tighten type constraint for RISCVISD::FCLASS_VL.

[lldb] Pass CMAKE_SYSROOT through to LLDB shell tests

This allows the LLDB Shell tests to succeed in (e.g. CI) environments where
system libraries are provided hermetically as a sysroot.

Reviewed By: JDevlieghere

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

[SLP][NFC]Add a test for spill cost, NFC.

[mlir][sparse][gpu] fix merge conflict

Reviewed By: Peiming

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

[lldb][NFCI] Include <cstdio> in SBDefines for FILE * definition

There are a few API headers that use FILE * but do not include the
correct header for their definition. Instead of including <cstdio> in each
of the headers manually, it seems easiest to include it in SBDefines to
get them all at once.

rdar://109579348

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

[libc++][PSTL] Add a test to make sure that customization points work properly

Reviewed By: #libc, ldionne

Spies: ldionne, libcxx-commits

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

SelectionDAG: Teach ComputeKnownBits about VSCALE

This reverts commit 9b92f70d4758f75903ce93feaba5098130820d40.  The issue
with the re-applied change was an implicit truncation due to the
multiplication.  Although the operations were converted to `APInt`, the
values were implicitly converted to `long` due to the typing rules.

Fixes: #59594

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

[clang-tidy] Optimize misc-confusable-identifiers

Main performance issue in this check were caused by many
calls to getPrimaryContext and constant walk up to declaration
contexts using getParent. Also there were issue with forallBases
that is slow.

Profiled with perf and tested on open-source project Cataclysm-DDA.
Before changes check took 27320 seconds, after changes 3682 seconds.
That's 86.5% reduction. More optimizations are still possible in this
check.

Reviewed By: serge-sans-paille

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

[libc++][ci] Install ccache in the Docker image

This will allow using ccache in the jobs that build Clang, which
should speed up those jobs.

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

Fix wrong error message when compiling C souce code:
Currently emit error for uses_allocators(alloc(traits)):

called object type 'omp_allocator_handle_t' (aka
'enum omp_allocator_handle_t') is not a function or function pointer

To fix this, since "alloc" is Id expresison(spce 5.2), during the parser
(in ParseOpenMP.cpp), using tryParseCXXIdExpression instead of
ParseExpression for C.

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

[mlir] [sparse] [gpu] adding transpose support to spmm spmv

Reviewed By: aartbik, wrengr

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

[Driver][X86] Reject unsupported value for -mabi=

-mabi= was incorrectly claimed before D134671. -mabi=sysv appears to be
somewhat common in open-source packages, even if it was not intended to
be supported by Clang.
(For common options supported by multiple architectures, it's easy to
forget to report an error on unsupported targets. Unfortunately
the driver infrastructure doesn't make this less error-prone.)

On x86, support -mabi=sysv for non-Windows targets and -mabi=ms for Windows,
and remove the spurious -Wunused-command-line-argument warning.

With this change, all popular architectures claim -mabi=, so we don't
have to worry much about -Wunused-command-line-argument for other
architectures.

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

hwasan: enable mmap interception (no tagging used)

This enables HWASan interception for mmap, to prevent users from allocating in the shadow memory regions. For compatibility, it does not use pointer tagging, nor does it allow MAP_FIXED with a tagged address.

This patch initializes the common interceptors, but that should be a no-op (except for the mmap interceptor), due to the disable-by-default nature of hwasan_platform_interceptors.h (from D150708). As the first patch to utilize this common interceptor machinery for HWASan, it also defines some macros (e.g., COMMON_INTERCEPT_FUNCTION) that will be useful as future interceptors are enabled.

TestCases/Posix/mmap_write_exec.cpp now passes for HWASan.

Reviewed By: kstoimenov, vitalybuka

Differential Revision: D151262

[lldb] Remove reproducer test suite (NFC)

The reproducer feature as well as the ability to capture or replay tests
with reproducers was removed. This removes the corresponding CMake
target.

[flang] Retain the sign of the argument for the result of fraction(0)

The f18 clause 16.9.80 description of the FRACTION(X) intrinsic states:

    Result Value. The result has the value ....
    If X has the value zero, the result is zero.
    If X is an IEEE NaN, the result is that NaN.
    If X is an IEEE infinity, the result is an IEEE NaN.

This clause does not specify whether fraction(-0.0) should be -0.0 or +0.0.
However, a folded result and a runtime result should be consistent, and
returning -0.0 is more in line with the result for fraction(NaN).

For this test:

  print '(2f6.1)', 0.0, fraction(0.0)
  call f(0.0)
  print '(2f6.1)', -0.0, fraction(-0.0)
  call f(-0.0)
  end

  subroutine f(x)
    print '(2f6.1)', x, fraction(x)
  end

Current output is:

   0.0   0.0
   0.0   0.0
  -0.0  -0.0
  -0.0   0.0

Change that to:

   0.0   0.0
   0.0   0.0
  -0.0  -0.0
  -0.0  -0.0

[VP][SelectionDAG][RISCV] Add get_vector_length intrinsics and generic SelectionDAG support.

The generic implementation is umin(TC, VF * vscale).

Lowering to vsetvli for RISC-V will come in a future patch.

This patch is a pre-requisite to be able to CodeGen vectorized code from
D99750.

Reviewed By: reames, frasercrmck

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

[MLIR][python bindings] Add TypeCaster for returning refined types from python APIs

depends on D150839

This diff uses `MlirTypeID` to register `TypeCaster`s (i.e., `[](PyType pyType) -> DerivedTy { return pyType; }`) for all concrete types (i.e., `PyConcrete<...>`) that are then queried for (by `MlirTypeID`) and called in `struct type_caster<MlirType>::cast`. The result is that anywhere an `MlirType mlirType` is returned from a python binding, that `mlirType` is automatically cast to the correct concrete type. For example:

```
      c0 = arith.ConstantOp(f32, 0.0)
      # CHECK: F32Type(f32)
      print(repr(c0.result.type))

      unranked_tensor_type = UnrankedTensorType.get(f32)
      unranked_tensor = tensor.FromElementsOp(unranked_tensor_type, [c0]).result

      # CHECK: UnrankedTensorType
      print(type(unranked_tensor.type).__name__)
      # CHECK: UnrankedTensorType(tensor<*xf32>)
      print(repr(unranked_tensor.type))
```

This functionality immediately extends to typed attributes (i.e., `attr.type`).

The diff also implements similar functionality for `mlir_type_subclass`es but in a slightly different way - for such types (which have no cpp corresponding `class` or `struct`) the user must provide a type caster in python (similar to how `AttrBuilder` works) or in cpp as a `py::cpp_function`.

Reviewed By: ftynse

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

[mlir] make `fuse_into_containing_op` preserve the containing op handle

This partially undoes the intent of https://reviews.llvm.org/D151418 by
cheating its way to keep the "containing op" (aka loop) handle read-only
in fusion. It is crucial to do so for composability of tiling and
fusion. Specfically, after the "containing op" handle started being
consumed, it became impossible to perform additional tiling after fusion
except tiling the last-fused op:

  %tiled1, %loop1 = tile %op
  %producer1, %loop2 = fuse %producer into %loop1
  // invalid, because %tiled1 is invalidated by consuming %loop1
  // that points to its parent
  tile %tiled1

or

  %tiled1, %loop1 = tile %op
  %tiled2, %loop2 = tile %tiled1
  %p2 = fuse %producer into %loop1
  // invalid, because %loop2 is invalidated by consuming %loop1
  // that points to its parent
  fuse %p2 into %loop2

The approach here makes creative use of the state extension mechanism to
update the payload operation associted with the operand handle. Further
investigation is necessary to understand if is consistent with the
overall execution model of the transform dialect, but it is crucial to
restore composability ASAP.

Reviewed By: springerm, nicolasvasilache

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

[mlir] teach expensive-checks transform mode about empty handle

The transform dialect interpreter features the expensive-checks mode
that acts as an embedded sanitizer to track use-after-consume of
transform handles. Its logic is based on the relations between payload
operations, which made it silently ignore empty handles that are
consumed. Also catch and report this case because the remaining code may
hit an assertion on attempting to access a consumed handle (that is
removed from the mapping).

Reviewed By: nicolasvasilache

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

[lldb] Improve error message when evaluating expression when not stopped

When trying to run an expression after a process has existed, you
currently are shown the following error message:

  (lldb) p strlen("")
  error: Can't make a function caller while the process is running

This error is wrong and pretty uninformative. After this patch, the
following error message is shown:

  (lldb) p strlen("")
  error: unable to evaluate expression while the process is exited: the
  process must be stopped because the expression might require
  allocating memory.

rdar://109731325

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

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

[FastISel] Implement translation of entry_value dbg.value intrinsics

For dbg.value intrinsics targeting an llvm::Argument address whose expression
starts with an entry value, we lower this to a DEBUG_VALUE targeting the livein
physical register corresponding to that Argument.

Depends on D151332

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

[gn build] Port 8d0412ce9d48

[RISCV] Revise test coverage for shuffle/insert idiom which become v(f)slide1ups

This fixes a couple mistakes in 0f64d4f877.  In particular, I'd not included a negative test where the slideup didn't write the entire VL, and had gotten all of my 4 element vector shuffle masks incorrect so they didn't match.  Also, add a test with swapped operands for completeness.

The transform is in D151468.

[gn] attempt to port fe2f0ab37c33

[InstCombine] Remove instructions in dead blocks during combining

We already do this during initial worklist population. Doing this
as part of primary combining allows us to remove instructions in
blocks that were rendered dead by condition folding within the
same instcombine iteration.

[ValueTracking] Avoid optimizing away condition in test (NFC)

This is not what we're interested in testing, and it allows to
essentially optimize away the entire function with more powerful
optimization.

[RISCV] Fix typo VLUpperBound to VLEN in SiFive7. NFC.

The scheduler models said VLUpperBound which was a typo and should have
said VLEN. This is a purley cosmetic fix.

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

[libc] Adapt includes after 25174976e19b2ef916bb94f4613662646c95cd46

[AArch64] merge scaled and unscaled zero narrow stores.

This patch fixes a crash when a sclaed and unscaled zero stores are merged.

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

[InstCombine] Optimize compares with multiple selects as operands

In case of a comparison with two select instructions having the same
condition, check whether one of the resulting branches can be simplified.
If so, just compare the other branch and select the appropriate result.
For example:

    %tmp1 = select i1 %cmp, i32 %y, i32 %x
    %tmp2 = select i1 %cmp, i32 %z, i32 %x
    %cmp2 = icmp slt i32 %tmp2, %tmp1

The icmp will result false for the false value of selects and the result
will depend upon the comparison of true values of selects if %cmp is
true. Thus, transform this into:

    %cmp = icmp slt i32 %y, %z
    %sel = select i1 %cond, i1 %cmp, i1 false

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

[Clang] Correctly handle generic lambda used as default template argument.

Adjust the template pparameter depth when parsing default
template arguments as they may introduce generic lambda whose parameters
are not substituted at the same depth.

Fixes #62611

Reviewed By: erichkeane, #clang-language-wg

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

[InstCombine] Add tests for icmp of select fold (NFC)

For D150360.

[InstCombine] Handle undef when pruning unreachable code

If the branch condition is undef, then behavior is undefined and
neither of the successors are live.

This is to ensure that optimization quality does not decrease
when a constant gets replaced with undef/poison in this context.

[ValueTracking] Avoid UB in test (NFC)

Don't use br undef, as it is UB.

[X86] fold select to mask instructions.

When avx512 is available the lhs operand of select instruction can be
folded with mask instruction, while the rhs operand can't. This patch is
to commute the lhs and rhs of the select instruction to create the
opportunity of folding.

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

[InstCombine] Add additional tests for unreachable code (NFC)

[LLDB] Explicitly declare constructor in `PersistentExpressionState`

It seems that when trying to link the lldb library explicitly, the inlined default constructor cannot find the vtable for the class. This patch fixes this by explicitly declaring a default constructor in `PersistentExpressionState`, and providing the definition in the source file.

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

[NFC] refactor code

Split the NFC patch from D151535. Refactor canCombineAsMaskOperation to
take 1 input operand.

[InstCombine] Add test for missing assume handling multi-use demanded bits (NFC)

Works if the assume is on a root value or an operation that does
not support multi-use demanded bits.

[InstCombine] Use KnownBits::shl() in SimplifyDemandedBits()

It is more precise than the custom logic we had. This came up when
trying to enforce a consistency assertion with computeKnownBits().

[KnownBits] Partially synchronize shift implementations (NFC)

And remove some bits of effectively dead code.

[mlir] Make sure mlir-opt is in the list of substituted tools

otherwise it gets picked up from $PATH, which is not always working
properly.

[KnownBits] Add fast-path for shl with unknown shift amount (NFC)

We currently don't call into KnownBits::shl() from ValueTracking
if the shift amount is unknown. If we do try to do so, we get
significant compile-time regressions, because evaluating all 64
shift amounts if quite expensive, and mostly pointless in this case.
Add a fast-path for the case where the shift amount is the full
[0, BitWidth-1] range. This primarily requires a more accurate
estimate of the max shift amount, to avoid taking the fast-path in
too many cases.

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

[bazel][libc] Add another missing dependency

[FastISel][NFC] Remove repeated calls to get{Variable,Expr}

This will make it easy to reuse these values in subsequent commits.

Depends on D151331

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

[FastISel][NFC] Refactor if/else chain into early returns

This will make it easier to add more cases in a subsequent commit and also
better conforms to the coding guidelines.

Depends on D151330

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

[SelectionDAGBuilder] Handle entry_value dbg.value intrinsics

Summary:
DbgValue intrinsics whose expression is an entry_value and whose address is
described an llvm::Argument must be lowered to the corresponding livein physical
register for that Argument.

Depends on D151329

Reviewers: aprantl

Subscribers:

[IRTranslator] Implement translation of entry_value dbg.value intrinsics

For dbg.value intrinsics targeting an llvm::Argument address whose expression
starts with an entry value, we lower this to a DEBUG_VALUE targeting the livein
physical register corresponding to that Argument.

Depends on D151328

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