Use the correct interface base type name when generating attribute interfaces
with TabeGen.

Reviewed By: ftynse

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

This combine step performs the following type of transformation:

    rev.p a0, a0   # grevi a0, a0, 0b01
    rev2.n a0, a0  # grevi a0, a0, 0b10
    -->
    rev.n a0, a0   # grevi a0, a0, 0b11

Reviewed By: craig.topper

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

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

We can't call getNumElements() for ScalableVectorType types - just bail for now, although ConstantAggregateZero/UndefValue could return a reasonable value.

Fixes crash shown in OSS-Fuzz #25272 https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=25272

1. Move ThreadPool ownership to the runtime, and wait for the async tasks completion in the destructor.
2. Remove MLIR_ASYNCRUNTIME_EXPORT from method definitions because they are unnecessary in .cpp files, as only function declarations need to be exported, not their definitions.
3. Fix concurrency bugs in group emplace and potential use-after-free in token emplace.

Tested internally 10k runs in `async.mlir` and `async-group.mlir`.

Fixed: https://bugs.llvm.org/show_bug.cgi?id=48267

Reviewed By: mehdi_amini

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

This reverts commit 2734a9eb.

This patch appeared to not be a NFC. It introduced an execution path where
monotonicity check on limited space started relying in existing nsw/nuw
flags, which is illegal. The motivating test will follow-up.

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

Adjusted external reference for Darwin/AARCH64 link compatibility.
Made size directive conditional only if __ELF__ defined.

Patch by Michael_Pique <mpique@icloud.com>

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

Needed for a future automatic update to RST.

Patch limits set of predicates seen by mutuallyExclusive to ones which belong
to current processor model. This needs to be done, because same predicate can
be used by multiple processor models which can make mutuallyExclusive over
optimistic.

This patch converts `0 - abs(x)` to `Y = sra (X, size(X)-1); sub (Y, xor (X, Y))` for better codegen.

Reviewed By: RKSimon

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

This:
1) Changes its signature.
2) Refines the name of local variable (`SymTabName`->`LinkedSecName`,
   because SHT_GNU_verneed/SHT_GNU_verdef are linked with the string table, not with the symbol table).
3) Stops using the `unwrapOrError` inside.

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

This stops using `RelocationRef` API in the `printStackSize` method
and starts using the "regular" API that is used in almost all other places
in ELFDumper.cpp.

This is not only makes the code to be more consistent, but helps to diagnose
issues better, because the `ELFObjectFile` API, which is used
currently to implement stack sized dumping sometimes has a behavior
that just doesn't work well for broken inputs.

E.g see how it gets the `symbol_end` iterator. It will just not work
well for a case when the `sh_size` is broken.

```
template <class ELFT>
basic_symbol_iterator ELFObjectFile<ELFT>::symbol_end() const {
...
  DataRefImpl Sym = toDRI(SymTab, SymTab->sh_size / sizeof(Elf_Sym));
  return basic_symbol_iterator(SymbolRef(Sym, this));
}
```

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

Patch fixes scheduling of ALU instructions which modify pc register. Patch
also fixes computation of mutually exclusive predicates for sequences of
variants to be properly expanded

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

D91867 introduced the `tryGetSectionName` helper.
But we have `getPrintableSectionName` member with the similar
behavior which we can reuse. This patch does it.

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

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

This file is intended to be included by other files, including
out-of-tree dialects, and makes more sense in `include` than in `lib`.

Depends On D91652

Reviewed By: mehdi_amini

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

This change makes llvm-elfabi tool to emit .dynsym and .dynamic
sections.

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

Attributes represent additional data about an operation and are intended to be
modifiable during the lifetime of the operation. In the dialect-specific Python
bindings, attributes are exposed as properties on the operation class. Allow
for assigning values to these properties. Also support creating new and
deleting existing attributes through the generic "attributes" property of an
operation. Any validity checking must be performed by the op verifier after the
mutation, similarly to C++. Operations are not invalidated in the process: no
dangling pointers can be created as all attributes are owned by the context and
will remain live even if they are not used in any operation.

Introduce a Python Test dialect by analogy with the Test dialect and to avoid
polluting the latter with Python-specific constructs. Use this dialect to
implement a test for the attribute access and mutation API.

Reviewed By: stellaraccident, mehdi_amini

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

GNU ld doesn't seem to do this though, but it looks like a reasonable
use case, is easy to implement, and was requested in
https://bugs.llvm.org/show_bug.cgi?id=47384.

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

The commit introduced a crash when emitting (debug info for) complex
floats (pr48277).

This uses the same reasoning as other similar conversions just before selection,
without it we miss out on selection because the importer considers s64 and p0
distinct types.

Tablegen seg faulted when parsing a Pat where the destination part has
no output (zero instruction), due to a register class lookup using
nullptr.

Reviewed By: Paul-C-Anagnostopoulos

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

The devirtualization wrapper misses cases where if it wraps a pass
manager, an individual pass may devirtualize an indirect call created by
a previous pass. For example, inlining may create a new indirect call
which is devirtualized by instcombine. Currently the devirtualization
wrapper will not see that because it only checks cgscc edges at the very
beginning and end of the pass (manager) it wraps.

This fixes some tests testing this exact behavior in the legacy PM.

Instead of checking WeakTrackingVHs for CallBases at the very beginning
and end of the pass it wraps, check every time
updateCGAndAnalysisManagerForPass() is called.

check-llvm and check-clang with -abort-on-max-devirt-iterations-reached
on by default doesn't show any failures outside of tests specifically
testing it so it doesn't needlessly rerun passes more than necessary.
(The NPM -O2/3 pipeline run the inliner/function simplification pipeline
under a devirtualization repeater pass up to 4 times by default).

http://llvm-compile-time-tracker.com/?config=O3&stat=instructions&remote=aeubanks
shows that 7zip has ~1% compile time regression. I looked at it and saw
that there indeed was devirtualization happening that was not previously
caught, so now it reruns the CGSCC pipeline on some SCCs, which is WAI.

The initial land assumed CallBase WeakTrackingVHs would always be
CallBases, but they can be RAUW'd with undef.

Reviewed By: asbirlea

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

The legacy pass didn't properly detect indirect calls.

We can still remove the convergent attribute when there are indirect
calls. The LangRef says:

> When it appears on a call/invoke, the convergent attribute indicates
that we should treat the call as though we’re calling a convergent
function. This is particularly useful on indirect calls; without this we
may treat such calls as though the target is non-convergent.

So don't skip handling of convergent when there are unknown calls.

Reviewed By: jdoerfert

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

Minor code refactor to improve readability.

This fixes the Builtins-sparc-linux testsuite failures on Linux
SPARC which occur because clang cannot find the 32-bit runtime
libraries when -m32 is passed on the command line. The same
workaround is already being used on X86 and PPC.

Also, switch the CHECK-DEBIAN-SPARC tests to use debian_multiarch_tree
as both sparc and sparc64 are using the MultiArch mechanism on modern Debian
systems the same way as x86_64, powerpc64el and others. Thus, switch the
CHECK-DEBIAN-SPARC32 and CHECK-DEBIAN-SPARC64 tests to use the files from
the debian_multiarch_tree directory for the header and linker path tests.

Finally, rename CHECK-DEBIAN-SPARC32 to CHECK-DEBIAN-SPARC to match the naming
scheme of the Debian MultiArch checks for the other Debian architectures.

Reviewed By: MaskRay, phosek

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

* Remove misnamed `PPC64_HAS_VMX` in preference of directly checking `defined(__VSX__)`.

libunwind was using "VMX" to mean "VSX". "VMX" is just another name for Altivec, while "VSX" is the vector-scalar extensions first used in POWER7. Exposing a "PPC64_HAS_VMX" define was misleading and incorrect.

* Add `defined(__ALTIVEC__)` guards around vector register operations to fix non-altivec CPUS such as the e5500.

When compiling for certain Book-E processors such as the e5500, we want to skip vector save/restore, as the Altivec registers are illegal on non-Altivec implementations.

* Add `!defined(__NO_FPRS__)` guards around traditional floating-point save/restore.

When compiling for powerpcspe, we cannot access floating point registers, as there aren't any. (The SPE on e500v2 is a 64-bit extension of the GPRs, and it doesn't have the normal floating-point registers at all.)
This fixes building for powerpcspe, although no actual handling for SPE save/rest...

llvm-config output with the gn build is just good enough to make
tests pass, but llvm-config wants all .a files it knows about to
actually exist. So let it know about fewer .a files that don't
exist if not all targets are enabled.

This patch fixes a minor typo in RegisterContextPOSIXProcessMonitor_arm64
constructor where memset target was wrongly specified as m_fpr instead of
m_gpr_arm64.

Extend TestProcessConnect to cover the scenario fixed by
6c0cd567. This replaces
command-process-connect.test which would fail if port 4321
was open.

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

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

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