Zero factor leads to division by zero and failure of corresponding
assert as shown in PR50765. We should filter out such factors.

Differential Revision: https://reviews.llvm.org/D104702
Reviewed By: huihuiz, reames

multiple_transpose -> multiply_transpose

GCC5 isn't able to implicitly capture `this` properly in an `auto` lambda.

This avoids generating otherwise unnecessary methods.

This introduces a CMake find module for detecting target offloading support in
a compiler. The goal is to make it easier to incorporate target offloading into
a cmake project.

Reviewed By: tianshilei1992

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

Remove the duplicate unnecessary CHECK labels at the bottom of the file.

It doesn't build there, see http://45.33.8.238/macm1/12180/step_4.txt

This revision refactors the usage of multithreaded utilities in MLIR to use a common
thread pool within the MLIR context, in addition to a new utility that makes writing
multi-threaded code in MLIR less error prone. Using a unified thread pool brings about
several advantages:

* Better thread usage and more control
We currently use the static llvm threading utilities, which do not allow multiple
levels of asynchronous scheduling (even if there are open threads). This is due to
how the current TaskGroup structure works, which only allows one truly multithreaded
instance at a time. By having our own ThreadPool we gain more control and flexibility
over our job/thread scheduling, and in a followup can enable threading more parts of
the compiler.

* The static nature of TaskGroup causes issues in certain configurations
Due to the static nature of TaskGroup, there have been quite a few problems related to
destruction that have caused several downstream projects to disable threading. See
D104207 for discussion on some related fallout. By having a ThreadPool scoped to
the context, we don't have to worry about destruction and can ensure that any
additional MLIR thread usage ends when the context is destroyed.

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

* `<type_traits>` depends on `std::forward`, so we replaced it with
  `static_cast<T&&>`.
* `swap`'s return type is confusing, so it's been rearranged to improve
   readabilitiy.

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

This patch makes PriorityInlineOrder lazily updated.
The PriorityInlineOrder would lazily update the desirability of a call site if it's decreasing.

Reviewed By: kazu

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

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

TSan only supports 64-bit platforms.

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

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

Bionic <malloc.h> may provide the definitions of M_MEMTAG_TUNING_* constants.
Do not redefine them in that case.

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

During template instantiation involving templated lambdas, clang
could hit an assertion in `TemplateDeclInstantiator::SubstFunctionType`
since the functions are not associated with any `TypeSourceInfo`:

`assert(OldTInfo && "substituting function without type source info");`

This path is triggered when using templated lambdas like the one added as
a test to this patch. To fix this:

- Create `TypeSourceInfo`s for special members and make sure the template
instantiator can get through all patterns.
- Introduce a `SpecialMemberTypeInfoRebuilder` tree transform to rewrite
such member function arguments. Without this, we get errors like:

`error: only special member functions and comparison operators may be defaulted`

since `getDefaultedFunctionKind` can't properly recognize these functions
as special members as part of `SetDeclDefaulted`.

Fixes PR45828 and PR44848

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

In a callback case, a return from internal code, say A, to external runtime can happen. The external runtime can then call back to another internal routine, say B. Making an artificial branch that looks like a return from A to B can confuse the unwinder to treat the instruction before B as the call instruction.

Reviewed By: wenlei, wmi

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

This reverts commit 21c008d5 since
it broke the build on macOS and Windows with the following error:

  The install of the clang_rt.<na,e> target requires changing an
  RPATH from the build tree, but this is not supported with the Ninja
  generator unless on an ELF-based platform.  The
  CMAKE_BUILD_WITH_INSTALL_RPATH variable may be set to avoid this relinking
  step.

getLineNumber() was counting the number of line feeds from the start of
the buffer to the current token. For large linker scripts this became a
performance bottleneck. For one 4MB linker script over 4 minutes was
spent in getLineNumber's StringRef::count.

Store the line number from the last token, and only count the additional
line feeds since the last token.

Reviewed By: MaskRay

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

This patch fixes a problem with the AAExecutionDomain attributor not
checking if it is in a valid state. This can cause it to incorrectly
return that a block is executed in a single threaded context after the
attributor failed for any reason.

Reviewed By: jdoerfert

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

[clang] unbreak Index/preamble-reparse-changed-module.m with LLVM_APPEND_VC_REV=NO after 7942ebdf

See revision b8b7a9dc for prior art.

Fixes clang cross-compilation.

Also remove some redundant include path arguments.

Reviewed By: gussmith23

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

We want to disable the use of undefined symbols on Fuchsia, but there
are cases where it might be desirable so may it configurable.

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

Cleanup sema checking for 64bit builtins or builtins that require
         specific feature support.

Reviewed By: NeHuang

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

Work around two problems with GCC 7.3.
One is its inability to implement "constexpr operator=(...) = default;"
in a class with a std::optional<> component; another is a legitimate-
looking warning about an unused variable.

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

After landing the globalization optimizations, the precense of globalization on
the device that was not put in shared or stack memory is a failed optimization
with performance consequences so it should indicate a missed remark.

Reviewed By: jdoerfert

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

They are already provided by Sema, deserializing from preamble if need
be. Moreover category names are meaningless outside interface/implementation
context, hence they were only causing noise.

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

Slowly we are moving toward full support of sparse tensor *outputs*. First
step was support for all-dense annotated "sparse" tensors. This step adds
support for truly sparse tensors, but only for operations in which the values
of a tensor change, but not the nonzero structure (this was refered to as
"simply dynamic" in the [Bik96] thesis).

Some background text was posted on discourse:
https://llvm.discourse.group/t/sparse-tensors-in-mlir/3389/25

Reviewed By: gussmith23

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

This change adds an option which, in addition to dumping the record
layout as is done by -fdump-record-layouts, causes us to compute the
layout for all complete record types (rather than the as-needed basis
which is usually done by clang), so that we will dump them as well.
This is useful if we are looking for layout differences across large
code bases without needing to instantiate every type we are interested in.

Reviewed By: dexonsmith

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

The OpenMP 5.1 standard defines the environment variable
`OMP_TEAMS_THREAD_LIMIT` to limit the number of threads that will be run in a
single block. This patch adds support for this into the AMDGPU and CUDA
plugins.

Reviewed By: jdoerfert

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

This used to be important for reducing lock contention when accessing identifiers, but
the cost of the cache can be quite large if parsing in a multi-threaded context. After
D104167, the win of keeping a cache is not worth the cost.

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

Operations currently rely on the string name of attributes during attribute lookup/removal/replacement, in build methods, and more. This unfortunately means that some of the most used APIs in MLIR require string comparisons, additional hashing(+mutex locking) to construct Identifiers, and more. This revision remedies this by caching identifiers for all of the attributes of the operation in its corresponding AbstractOperation. Just updating the autogenerated usages brings up to a 15% reduction in compile time, greatly reducing the cost of interacting with the attributes of an operation. This number can grow even higher as we use these methods in handwritten C++ code.

Methods for accessing these cached identifiers are exposed via `<attr-name>AttrName` methods on the derived operation class. Moving forward, users should generally use these methods over raw strings when an attribute name is necessary.

Differential Revision: http...

This was crbug.com/1222724, which caused D104529 to be reverted. The
new test fails when D104529 is reapplied locally.

This patch introduces configuration for a Bazel BUILD in a side
directory in the monorepo.

This is following the approval of
https://github.com/llvm/llvm-www/blob/main/proposals/LP0002-BazelBuildConfiguration.md

As detailed in the README, the Bazel BUILD is not supported
by the community in general, and is maintained only by interested
parties. It follows the requirements of the LLVM peripheral tier:
https://llvm.org/docs/SupportPolicy.html#peripheral-tier.

This is largely copied from https://github.com/google/llvm-bazel,
with a few filepath tweaks and the addition of the README.

Reviewed By: echristo, keith, dblaikie, kuhar

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

Currently the lambda body indents relative to where the lambda signature is located. This instead lets the user
choose to align the lambda body relative to the parent scope that contains the lambda declaration. Thus:

someFunction([] {
  lambdaBody();
});

will always have the same indentation of the body even when the lambda signature goes on a new line:

someFunction(
    [] {
  lambdaBody();
});

whereas before lambdaBody would be indented 6 spaces.

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