This combines two separate ops (D88972: `gpu.create_token`, D89043: `gpu.host_wait`) into one.

I do after all like the idea of combining the two ops, because it matches exactly the pattern we are
going to have in the other gpu ops that will implement the AsyncOpInterface (launch_func, copies, alloc):

If the op is async, we return a !gpu.async.token. Otherwise, we synchronize with the host and don't return a token.

The use cases for `gpu.wait async` and `gpu.wait` are further apart than those of e.g. `gpu.h2d async` and `gpu.h2d`,
but I like the consistent meaning of the `async` keyword in GPU ops.

Reviewed By: herhut

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

Implement computeKnownBitsForTargetInstr for G_AMDGPU_BUFFER_LOAD_UBYTE
and G_AMDGPU_BUFFER_LOAD_USHORT. This allows generic combines to remove
some unnecessary G_ANDs.

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

We are still implementing our own logic for this that looks for a VCS file in
the place where it was before the monorepo migration. This removes this logic
and just uses the CMake function that LLVM/Clang are using.

Reviewed By: JDevlieghere, kastiglione

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

While debugging another bug I found out that we currently don't set any limit
for the number of diagnostics Clang emits. If a user does something that
generates a lot of errors (like including some long header file from within the
expression function), then we currently spam the LLDB output with potentially
thousands of Clang error diagnostics.

Clang sets a default limit of 20 errors, but given that LLDB is often used
interactively for small expressions I would say a limit of 5 is enough. The
limit is implemented as a setting, so if a user cares about seeing having a
million errors printed to their terminal then they can just increase the
settings value.

Reviewed By: shafik, mib

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

RegisterInfo's `reg_name`/`reg_alt_name` fields are C-Strings and are supposed
to only be generated from a ConstString. The reason for that is that
`DynamicRegisterInfo::GetRegisterInfo` and
`RegInfoBasedABI::GetRegisterInfoByName` try to optimise finding registers by
name by only comparing the C string pointer values instead of the underlying
strings. This only works if both C strings involved in the comparison come from
a ConstString. If one of the two C strings doesn't come from a ConstString the
comparison won't work (and most likely will silently fail).

I added an assert in b0060c3a which checks that
both strings come from a ConstString. Apparently not all ABI plugins are
generating their register names via ConstString, so this code is now not just
silently failing but also asserting.

In D88375 we did a shady fix for the MIPS plugins by just copying the
ConstString setup code to that plugin, but we still need to fix ABISysV_arc,
ABISysV_ppc and ABISysV_ppc64 plugins.

I would say we just fix the remaining plugins by removing the whole requirement
to have the register names coming from ConstStrings. I really doubt that we
actually save any time with the whole ConstString search trick (searching ~50
strings that have <4 characters doesn't sound more expensive than calling the
really expensive ConstString constructor + comparing the same amount of pointer
values). Also whatever small percentage of LLDB's runtime is actually spend in
this function is anyway not worth the complexity of this approach.

This patch just removes all this and just does a normal string comparison.

Reviewed By: JDevlieghere, labath

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

That's supposed to be used to implement things such as `settings set target.run-args{basename==test&&arch==x86_64} arg1`
but it's not actually fully implemented or tested anywhere.

Reviewed By: JDevlieghere

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

This patch adds several build system targets that run the normal test suite but
against the Watch/TV/iPhone simulators.

Reviewed By: JDevlieghere

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

Adds more testing in basic-assembly.s and a new test tables.s.
Adds support to yaml reading and writing of tables as well.

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

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

This provides coverage for existing special-cases and
a sampling of other intrinsics. Current output appears
to be wrong in several cases.

This PR adds support for identified and recursive structs.
This includes: parsing, printing, serializing, and
deserializing such structs.

The following C struct:

```C
struct A {
  A* next;
};
```

which is translated to the following MLIR code as:

```mlir
!spv.struct<A, (!spv.ptr<!spv.struct<A>, Generic>)>
```

would be represented in the SPIR-V module as:

```spirv
OpName %A "A"
OpTypeForwardPointer %APtr Generic
%A = OpTypeStruct %APtr
%APtr = OpTypePointer Generic %A
```

In particular the following changes are included:
- SPIR-V structs can now be either identified or literal
  (i.e. non-identified).
- All structs now have their members surrounded by a ()-pair.
- For recursive references,
  (1) an OpTypeForwardPointer instruction is emitted before
  the OpTypeStruct instruction defining the recursive struct
  (2) an OpTypePointer instruction is emitted after the
  OpTypeStruct instruction which actually defines the recursive
  pointer to struct type.

Reviewed By: antiagainst, rriddle, ftynse

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

There are several places in LLVM's CMake setup that try to remove the
`stdlib=...` flag from the CMake flags. All this code however only considered
the `-stdlib=` variant of the flag but not the alternative spelling with a
double dash. This causes that when one adds `--stdlib=...` to the user-provided
CMake flags that this gets transformed into just `-` which ends up causing the
build system to think it should read the source from stdin (which then lead to
very confusing build errors).

This just adds the alternative spelling before the`-stdlib=` variant in all
these places

Reviewed By: ldionne

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

I recently had to run the test suite with a debug Python which got started
warning about some invalid escape sequences in LLDB's Python code. They all
attempt to add a backslash by doing a single backslash instead of a double
backslash in a normal string. This seems to work fine for now, but Python says
this behaviour is deprecated, so this patch turns all those strings into raw
strings (where a single backslash is actually a single backslash)

Reviewed By: JDevlieghere

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

Fix typos in it and the TableGen Backend Developer's Guide.

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

Based on the recent patches D88475 and D88429 where we are losing undef values due to extension/comparisons.

I've added a Constant::mergeUndefsWith method that merges the undef scalar/elements from another Constant into a specific Constant.

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

We can use m_ConstantInt without a result value as we don't ever use it.

It didn't help.

This reverts commit bddef54c.

This appears to have been an omission in D83536.

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

This simplifies the workflow for adding new feature-test macros for
contributors. Previously, they would have to move the generated <version>
header from a temporary directory to libc++'s include directory by hand.
This makes the behavior for the <version> header consistent with what's
done for the tests and the documentation.

Change EmitAsmStmt() to

- Not tie physregs with the "+r" constraint, but instead add the hard
  register as an input constraint. This makes "+r" and "=r":"r" look the same
  in the output.

  Background: Macro intensive user code may contain inline assembly
  statements with multiple operands constrained to the same physreg. Such a
  case (with the operand constraints "+r" : "r") currently triggers the
  TwoAddressInstructionPass assertion against any extra use of a tied
  register. Furthermore, TwoAddress will insert a COPY to that physreg even
  though isel has already done so (for the non-tied use), which may lead to a
  second redundant instruction currently. A simple fix for this is to not
  emit tied physreg uses in the first place for the "+r" constraint, which is
  what this patch does.

- Give an error on multiple outputs to the same physical register.

  This should be reported and this is also what GCC does.

Review: Ulrich Weigand, Aaron Ballman, Jennifer Yu, Craig Topper

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

It seems that if codesigning the test executables with the
`com.apple.private.security.no-sandbox` entitlement then the simulator refuses
to launch them and every test fails with `Process launch failed: process exited
with status -1 (no such process.)`.

This patch checks if we're trying to run the test suite on the simulator and
then avoids signing the executable with `no-sandbox`.

Reviewed By: JDevlieghere

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

If the SDK name passed to dotest can't be found by `xcrun` we silently fall back
to the default SDK. This leads to rather cryptic errors being reported later on
when linking the actual test executables.

Instead just directly log and abort when this situation is encountered and
inform the user about the invalid argument.

Reviewed By: JDevlieghere

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

When running the test suite against the Watch/AppleTV simulator we currently hitting
the unimplemented parts of PlatformDarwin for the respective simulator platforms.

This just adds the respective switch cases.

This whole code path depends on having a valid Target, so can't just unittest this code
without refactoring it. So instead this is tested by just running the testsuite against
the respective simulators (which is how I found this).

Reviewed By: aprantl

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

Testing for the various cost model "TargetCostKind" is limited,
and testing for scalable vectors is limited. The motivating
example of an intrinsic is not included here yet because that
just crashes.

After D88666, which implemented DirectoryWatcher on Windows, we're
seeing test failures on Chromium's Windows bots.

Try raising the timeout in case the test is failing due to high load on
the machine.

Commit 6e56046f may trigger SEGV in llvm-tablegen if the latter
is built with -DLLVM_OPTIMIZED_TABLEGEN=OFF. The reason of SEGV was
accessing stale memory after expansion of std::vector.

This adds a new set of tests for upcoming constraint elimination
changes.

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

Followup to D85191.

This changes getTypeInfoInChars to return a TypeInfoChars
struct instead of a std::pair of CharUnits. This lets the
interface match getTypeInfo more closely.

Reviewed By: efriedma

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

Reviewed By: leonardchan

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

When the first operand is a null pointer we can avoid making a G_PTR_ADD and
make a G_INTTOPTR with the offset operand.
This helps us avoid making add with 0 later on for targets such as AMDGPU.

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

(ABS (SUB (EXTEND a), (EXTEND b))) to ZERO_EXTEND((UABD a, b))
(ABS (SUB (SIGN_EXTEND a), (SIGN_EXTEND b))) to ZERO_EXTEND((SABD a, b))

This partially solves the bug: https://bugs.llvm.org/show_bug.cgi?id=46888
Meta ticket: https://bugs.llvm.org/show_bug.cgi?id=46929

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

Breaks android build.
asan_malloc_dispatch_k needs memalign interceptor disabled in this patch.

This reverts commit a2291a58.

It introduced a memory leak.

This reverts commit 525b085a.

A dynamic linker with lazy binding support may need to handle variant
PCS function symbols specially, so an ELF symbol table marking
STO_AARCH64_VARIANT_PCS [1] was added to address this.

Function symbols that follow the vector PCS are marked via the
.variant_pcs assembler directive, which takes a single parameter
specifying the symbol name and sets the STO_AARCH64_VARIANT_PCS st_other
flag in the object file.

[1] https://github.com/ARM-software/abi-aa/blob/master/aaelf64/aaelf64.rst#st-other-values

Reviewed By: sdesmalen

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