There's only one use and it eventually converts the pointer into a
reference. Simplify things and always use references.

Without this patch in expressions like `foo += 1` reference `foo` has no
read and write roles.

This happens because `CompoundAssignOperator` is also a
`BinaryOperator`, thus handling `CompoindAssignOperator` in `else`
branch is a dead code.

This allows some basic variadic operands in rewrites. There were some workarounds employed (like "aliasing" the attribute). Couldn't find a way to do this directly with properties.

This adds test coverage for a crash exposed by
d311126349b8fe1684d62154a9fa5a7bbb0b713.

Using `true` as a no-op unfortunately does not work on windows, which
fails libcxx lit tests on windows. Lit provides the `:` internal shell
builtin which is equivalent to `true`.

This patch populates the GPU version of `libm` with missing vendor entrypoints. The vendor math entrypoints are disabled by default but can be enabled with the CMake option `LIBC_GPU_VENDOR_MATH=ON`.

CompileUnit::SetSupportFiles had two overloads, one that took and lvalue
reference and one that takes an rvalue reference. This removes both and
replaces it with an overload that takes the FileSpecList by value and
moves it into the member variable.

Because we're storing the value as a member, this covers both cases. If
the new FileSpecList was passed by lvalue reference, we'd copy it into
the member anyway. If it was passed as an rvalue reference, we'll have
created a new instance using its move and then immediately move it again
into our member. In either case the number of copies remains unchanged.

As mentioned in #69619, C23 6.7.2.2p5 explicitly prohibits using a
_BitInt as an underlying type to an enumeration. While we had this in
the _ExtInt implementation, the justification for that limitation in C
is compelling, so this is being removed to be compatible with the C23
standard.

Fixes: #69619

[ELF][test] Demonstrate --no-allow-shlib-undefined behavior with a hidden relocatable object file definition

1981b1b6 improved the check.

To calculate the LMUL with the same SEW/LMUL ratio when providing
EEW.

Eliding the vReg to NZCV conversion instruction for G_UADDE/... is illegal if
it causes the carry generating instruction to become dead because ISel
will just remove the dead instruction.
I accidentally introduced this here: https://reviews.llvm.org/D153164.
As far as I can tell, this is not exposed on the default clang settings,
because on O0 there is always a G_AND between boolean defs and uses, so
the optimization doesn't apply. Thus, when I tried to commit
https://reviews.llvm.org/D159140, which removes these G_ANDs on O0, I
broke some UBSan tests.
We fix this by recursively selecting the previous (NZCV-setting) instruction before continuing selection for the current instruction.

See-also: https://github.com/llvm/llvm-project/pull/69548

At the moment, all alloc-like functions are assumed to return non-null
pointers, if their return value is only used in a compare. This is based
on being allowed to substitute the allocation function with one that
doesn't fail to allocate the required memory.

aligned_alloc however must also return null if the required alignment
cannot be satisfied, so I don't think the same reasoning as above can be
applied to it.

This patch adds a bail-out for aligned_alloc calls to
isAllocSiteRemovable.

This patch addresses the missed review comment from PR #67063. It
renames LIT flag "--disable-gtest-sharding" to "--no-gtest-sharding"
and corrects the code style issue.

Otherwise you will likely get crashes.

This function was returning failure when any of the intersection sets
was empty, but this is actually legitimate in "matrix times vector"
cases, where some of the operands have lower dimensionality, implying
unit-dimension semantics for the "missing" dimensions.

Example:

```mlir
func.func @transpose_extend_batch_matmul(
    %vec: tensor<32x128xi16>,
    %mat: tensor<11008x32x128xi4>) -> tensor<11008x32xi32> {
  %c0_i32 = arith.constant 0 : i32
  %cst_0 = arith.constant 0.000000e+00 : f32
  %0 = tensor.empty() : tensor<11008x32xi32>
  %1 = linalg.fill ins(%c0_i32 : i32) outs(%0 : tensor<11008x32xi32>) -> tensor<11008x32xi32>
  %2 = tensor.empty() : tensor<11008xf32>
  %3 = linalg.fill ins(%cst_0 : f32) outs(%2 : tensor<11008xf32>) -> tensor<11008xf32>
  %batch_matmul_result = linalg.generic {indexing_maps = [affine_map<(d0, d1, d2) -> (d1, d2)>, 
                                                          affine_map<(d0, d1, d2) -> (d0, d1, d2)>, 
                                                          affine_map<(d0, d1, d2) -> (d0, d1)>], 
                                         iterator_types = ["parallel", "parallel", "reduction"]} 
                                         ins(%vec, %mat : tensor<32x128xi16>, tensor<11008x32x128xi4>) 
                                         outs(%1 : tensor<11008x32xi32>) {
  ^bb0(%in: i16, %in_3: i4, %out: i32):
      %19 = arith.extsi %in : i16 to i32
      %20 = arith.extui %in_3 : i4 to i32
      %21 = arith.muli %19, %20 : i32
      %22 = arith.addi %21, %out : i32
      linalg.yield %22 : i32
  } -> tensor<11008x32xi32>
  return %batch_matmul_result : tensor<11008x32xi32>
}
```

Here, we were returning failure because `ac` is empty. With this PR, we
return this useful information:

```
batch: [ 1 ]
m: [ ]
n: [ 0 ]
k: [ 2 ]
```

Regression caused by e880e8ae

Due to aux-target mismatch. Add -target option to fix aux-target.

https://lab.llvm.org/buildbot/#/builders/230/builds/20138

Rename lldb-vscode to lldb-dap. This change is largely mechanical. The
following substitutions cover the majority of the changes in this
commit:

  s/VSCODE/DAP/
  s/VSCode/DAP/
  s/vscode/dap/
  s/g_vsc/g_dap/

Discourse RFC:
https://discourse.llvm.org/t/rfc-rename-lldb-vscode-to-lldb-dap/74075/

In ef762e5e7292, I shifted around where errors were reported when
failing to parse and/or validate DWARFUnitHeaders. When we are doing so
in DWARFContext::fixupIndex, the actual error message isn't prefixed
with `warning:` like it would be elsewhere (because of the way
`logAllUnhandledErrors` is implemented).

Previously we were just matching against a fixed list of VP intrinsics
that we
knew couldn't be speculated, but we can reuse the logic in
isSafeToSpeculativelyExecuteWithOpcode. This also allows speculation in
more
cases, e.g. when the divisor is known to be non-zero.

Unfortunately we can't reuse the exact same function call for VP
intrinsics
with functional intrinsics instead of opcodes, because
isSafeToSpeculativelyExecute needs an instruction that already exists.
So this
just copies the logic by peeking into the function attributes of the
intrinsic.

As described in: https://github.com/ARM-software/acle/pull/257

Patch by: Kerry McLaughlin <kerry.mclaughlin@arm.com>

Reviewed By: david-arm

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

- Be explicit about which program resource register is supported by
which target
    - RSRC1
      - FP16_OVFL is GFX9+
      - WGP_MODE is GFX10+
      - MEM_ORDERED is GFX10+
      - FWD_PROGRESS is GFX10+
    - RSRC3
      - INST_PREF_SIZE is GFX11+
      - TRAP_ON_START is GFX11+
      - TRAP_ON_END is GFX11+
      - IMAGE_OP is GFX11+
  - Do not emit GFX11+ fields when disassembling GFX10 code objects
  - Tighten enforcement of reserved bits in disassembler

---------

Co-authored-by: Konstantin Zhuravlyov <kzhuravl@amd.com>

Updates:
1. Verification of block sparsity.
2. Verification of singleton level type can only follow compressed or
loose_compressed levels. And all level types after singleton should be
singleton.
3. Added getBlockSize function.
4. Added an invalid encoding test for an incorrect lvlToDim map that
user provides.

stack-uas.c and stack-history-length.c both have
-hwasan-record-stack-history=libcall, which makes the stack base
tag fully randomized. They may therefore sometimes have a zero tag
for a stack allocated variable, resulting in a false negative

(https://github.com/llvm/llvm-project/issues/69221#issuecomment-1767322411).

This patch applies the same workaround as used for deep-recursion.c

(https://github.com/llvm/llvm-project/commit/aa4dfd3736dd1c2e0263eacd09bd613c5784ea73)
and stack-uar.c

(https://github.com/llvm/llvm-project/commit/ddf1de20a3f7db3bca1ef6ba7e6cbb90aac5fd2d):
have two adjacent stack-allocated variables, and use whichever is not
zero-tagged.

These are the last remaining test cases that use
-hwasan-record-stack-history=libcall.

stack-uas flakiness spotted in the wild:
https://lab.llvm.org/buildbot/#/builders/269/builds/549/steps/11/logs/stdio
stack-history-length:
https://lab.llvm.org/buildbot/#/builders/269/builds/537



Co-authored-by: Thurston Dang <thurston@google.com>

As described in: https://github.com/ARM-software/acle/pull/257

Patch by: David Sherwood <david.sherwood@arm.com>

Reviewed By: dtemirbulatov

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

This is just a slight specialization of `TypesMatchWith` that returns
success if an optional parameter is missing.

There may be other places this could help e.g.:

https://github.com/llvm/llvm-project/blob/eb21049b4b904b072679ece60e73c6b0dc0d1ebf/mlir/include/mlir/Dialect/X86Vector/X86Vector.td#L58-L59
...but I'm leaving those to avoid some churn.

This constraint will be handy for us in some later patches, it's a
formalization of a short circuiting trick with the `comparator` of the
`TypesMatchWith` constraint (devised for #69195).

```
TypesMatchWith<
  "padding type matches element type of result (if present)",
  "result", "padding",
  "::llvm::cast<VectorType>($_self).getElementType()",
  // This returns true if no padding is present, or it's present with a type that matches the element type of `result`.
  "!getPadding() || std::equal_to<>()">
```

This is a little non-obvious, so after this patch you can instead do:
```
OptionalTypesMatchWith<
  "padding type matches element type of result (if present)",
  "result", "padding",
  "::llvm::cast<VectorType>($_self).getElementType()">
```

clang-cl is a driver mode that accepts options of MSVC cl.exe as a
drop-in replacement for cl.exe. Currently clang-cl accepts mixed clang
style options and cl style options. To let clang-cl accept a clang-style
option, just need to add visibility CLOption to that option.

Currently nvcc can pass cl style options to cl.exe, which allows nvcc to
compile C++ and CUDA programs with mixed nvcc and cl style options. On
the other hand, clang cannot use mixed clang and cl style options to
compile CUDA/HIP programs.

This patch add visibility CLOption to options needed to compile CUDA/HIP
programs. This allows clang-cl to compile CUDA/HIP programs with mixed
clang and cl style options.

It's not a verifier enforced property that implicit_def may only have
one operand. Fixes assertions after the coalescer implicit-defs to
preserve super register liveness to arbitrary instructions.

For some reason I'm unable to reproduce this as a MIR test running only
the allocator for the x86 test. Not sure it's worth keeping around.

Instead of raising an error for a misplaced `end loop directive`, just
warn about it and ignore it. This directive is an extension and is
optional.