Ports:
- core feature: https://reviews.llvm.org/D67039
- case mismatch: https://reviews.llvm.org/D70506
- extern "C" suggestions: https://reviews.llvm.org/D69592,
  https://reviews.llvm.org/D69650

Does not port https://reviews.llvm.org/D71735 since I believe that that doesn't
apply to lld/Mach-O.

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

* Remove -no-canonical-prefixes. See 98067998
* Test a.out and %t.out in few tests and remove excess `-o %t.o`
* Avoid wrapping lines too aggresstively
* Replace `"{{[^"]*}}ld{{(\.(lld|bfd|gold))?}}{{(\.exe)?}}"` with `ld{{(.exe)?}}"`. The new pattern supports more CLANG_DEFAULT_LINKER.

This patch enables libc++ build as shared library in all combinations of ASCII/EBCDIC and 32-bit/64-bit variants. In particular it introduces:

  # ASCII version of libc++ named as libc++_a.so
  # Script to rename DLL name inside the generated side deck
  # Various names for dataset members where DLL libraries and their side decks will reside
  # Add the following options:

   - LIBCXX_SHARED_OUTPUT_NAME
   - LIBCXX_ADDITIONAL_COMPILE_FLAGS
   - LIBCXX_ADDITIONAL_LIBRARIES
   - LIBCXXABI_ADDITIONAL_COMPILE_FLAGS
   - LIBCXXABI_ADDITIONAL_LIBRARIES

**Background and rational of this patch**

The linker on z/OS creates a list of exported symbols in a file called side deck. The list contains the symbol name as well as the name of the DLL which implements the symbol. The name of the DLL depends on what is specified in the -o command line option. If it points to a USS file, than the DLL name in the side deck will be the USS file name. If it points to a ...

Noticed this falling back on CTMark at -Os (bullet).

Seems like we have no 1:1 matching for it, so match SDAG and just lower.

Add testcases for common legal cases as well.

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

Reviewed By: Peiming

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

Reviewed By: aeubanks

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

This reverts commit 11adae50.
There are multiple aspects this change is not appealing.

* They conflict with JoinedOrSeparate `-o`. The old exception `-objc-*`
  should not be used an excuse.
* We generally want new options to be more rigid and avoid multiple
  spellings.
* If users get used to `-offload-*`, a misspelled `-offload-*` option still
  gets passed as `-o ffloat-*` without being detected.

Before this patch the code in printScalarConstant was unable to handle
nested constant expressions like (gep (addrspacecast ptr)) and crashed
with:

LLVM ERROR: Unsupported expression in static initializer:
  addrspacecast ([4 x i8] addrspace(1)* @ga to [4 x i8]*)

We can use lowerConstantForGV instead which is a customized version of
lowerConstant that supports generic() and nested expressions.

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

1) Fixed a typo in PTXAS_EXECUTABLE CMake variable (PXTAS -> PTXAS).

2) Version check was implemented incorrectly,
   now version (major, minor) is converted to int for comparison.

3) ptxas -arch argument was incorrect (or missing) in 3 tests.

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

This option forces constructors and non-deleting destructors to return
`this` pointer in C++ ABI (except for Microsoft ABI, on which this flag
has no effect).

This is similar to ARM32, Apple ARM64, or Fuchsia C++ ABI, but can be
applied to any target triple.

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

This change enables a declaration to be conveniently displayed within
a debugger when only a pointer to its DeclContext is available. For example,
in gdb:
  (gdb) p Ctx
  $1 = (const clang::DeclContext *) 0x14c1a580
  (gdb) p Ctx->dumpAsDecl()
  ClassTemplateSpecializationDecl 0x14c1a540 <t.cpp:1:1, line:7:1> line:2:8 struct ct
  `-TemplateArgument type 'int'
    `-BuiltinType 0x14bac420 'int'
  $2 = void

In the event that the pointed to DeclContext is invalid (that it has an
invalid DeclKind as a result of a dangling pointer, memory corruption, etc...)
it is not possible to dump its associated declaration. In this case, the
DeclContext will be reported as invalid. For example, in gdb:
  (gdb) p Ctx->dumpAsDecl()
  DeclContext 0x14c1a580 <unrecognized Decl kind 127>
  $3 = void

With this patch, TypedefTypes and UsingTypes can have an
underlying type which diverges from their corresponding
declarations.

For the TypedefType case, this can be seen when getting
the common sugared type between two redeclarations with
different sugar.

For both cases, this will become important as resugaring
is implemented, as this will allow us to resugar these
when they were dependent before instantiation.

Signed-off-by: Matheus Izvekov <mizvekov@gmail.com>

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

This patch converts test cases that simly could be rewritten
using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

Reviewed By: Peiming

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

[RISCV] Generalize select (and (x , 0x1) == 0), y, (z ^ y) ) and select (and (x , 0x1) == 0), y, (z | y) ) transforms by removing and-clause

These transforms were recently added (by me) in D134881. Looking at the code again, I realized we don't need the (and x, 0x1) portion of the pattern, we just need to know that the result of that sub-tree is either 0 or 1. Checking for this directly allows us to match slightly more broadly. The test changes are zext i1 arguments, but this could also kick in for e.g. shifts of high bits, or any other source of known bits.

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

This fixes a long standing cause of awful code generation when legalization creates
G_SEXT(G_FCMP(...)), for example due to promoting the condition of a vector G_SELECT.

Since on AArch64 vector compares sign-extend the condition value, there's no need
for this extra G_SEXT. Unfortunately by the time we get to post-legalization these
G_SEXTs have already been lowered into shifts, so this combine is a bit more
involved than I'd ideally like. Oh well.

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

Vector support seems to work immediately, as long as we run the combine before
legalization (so the vector SELECTs don't get lowered) and the legalizer rules
are there to enable generation.

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

Test cases were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

Fix assert in IndexCastUI folding and add tests for both IndexCastOp and
IndexCastUIOp folding

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

These tests cases were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34.

Needed to also re-run update_test_checks.py, otherwise some of them
would fail.

These tests cases were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34,
but there was also a need to re-run update_test_checks.py (impacting
nonnull/dereferencable attributes).

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

These tests cases were converted using the script at
https://gist.github.com/nikic/98357b71fd67756b0f064c9517b62a34

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

This adds a `--no-implicit-module` option, which disables the insertion
of a top-level `builtin.module` during parsing. Although other ops can
now be parsed as top-level, the actual reduction passes are still
restricted to `builtin.module` as it didn't seem straightforward to
update them.

Reviewed By: rriddle

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

This patch incorporates the "sanitize" step of the transitive includes
test into the CSV generator itself. In doing so, it removes complexity
in the test but also fixes a bug where we would filter out <__mutex>
from the output, leading to an incorrect list of includes for the
<shared_mutex> header.

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

If we can not prove that f16 operands of a buildvector are canonicalized, then we can not lower into a V_PACK. In this scenario, we would previously lower into some combination of and(sdwa), shr, or. This patch allows for matching into V_PERM instead.

Change-Id: Ifa4a74fdb81ef44f22ba490c7fdf81ec8aebc945

Also add test coverage for important debug output.

We have a very common pattern of dispatching between BUILD_VECTOR and SPLAT_VECTOR creation repeated in many cases in code.  Common the pattern into a utility function.

As fallout of the Deferred Concept Instantiation patch (babdef27), we
got a number of reports of a regression, where we asserted when
instantiating a constraint on a generic lambda inside of a variable
template. See: https://github.com/llvm/llvm-project/issues/57958

The problem was that getTemplateInstantiationArgs function only walked
up declaration contexts, and missed that this is not necessarily the
case with a lambda (which can ALSO be in a separate context).

This patch refactors the getTemplateInstantiationArgs function in a way
that is hopefully more readable, and fixes the problem with the concepts
on a generic lambda.

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

The region within sparse_tensor.select is used as the runtime criteria
for whether to keep the existing value in the sparse tensor.

While the sparse element is provided to the comparison, indices may also
be used to decide on whether to keep the original value. This allows, for
example, to only keep the upper triangle of a matrix.

Reviewed by: aartbik

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

This adds a `--no-implicit-module` option, which disables the insertion
of a top-level `builtin.module` during parsing. The top-level op is
required to have the `SymbolTable` trait.

The majority of the change here is removing `ModuleOp` from interfaces.

Reviewed By: rriddle

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

VMV_V_X_VL nodes should always have a passthru, a splat, and a VL.
We were sometimes missing the VL.

This went unnoticed because these cases were all selected into the
following node to form a .vx or .vi instruction. The ComplexPattern
that does this, doesn't check the VL operand. I've added an assert
to the ComplexPattern to catch if the operand is missing.

@qcolombet spotted some of these in D134703.

Previously, AggregateStores were created for aggregates associated with common
blocks. As a) AggregateStoreMap uses scope and offset information to search for
aggregate stores and b) variables related to common blocks have their
offsets set relative to the common block itself, if there were multiple
equivalences and at least one involved variables defined in a common block there
was an opportunity for the scope/offset pairs to match between distinct
aggregate stores. As a result, entries in AggregateStoreMap could collide,
resulting in incorrect stores being returned for a particular variable.

To prevent these collisions, skip creating AggregateStores for aggregates which
are associated with common blocks. This information was already unused as
aggregates associated with common blocks are handled by instantiateCommon.

Fixes https://github.com/llvm/llvm-project/issues/57749

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

This reverts commit 2138ef35.

Forgot to squash

This reverts commit 4c03c9f3.

Forgot to squash

VMV_V_X_VL nodes should always have a passthru, a splat, and a VL.
We were sometimes missing the VL.

This went unnoticed because these cases were all selected into the
following node to form a .vx or .vi instruction. The ComplexPattern
that does this, doesn't check the VL operand. I've added an assert
to the ComplexPattern to catch if the operand is missing.

@qcolombet spotted some of these in D134703.