We should be able to look through pointer casts that do not impact the
value.

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

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

This will allow running back-deployment testing on macOS only on systems
running the right version of macOS. For the time being, we're cheating
because we don't have actual machines running older than 10.15.

This reverts commit b7d80058.

The mlir-windows buildbot is broken.

Fixes usage of shared_ptr with CFI enabled, which is llvm.org/pr48993.

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

Convert `assertTrue(a == b)` to `assertEqual(a, b)` to produce better failure messages.

These were mostly done via regex search & replace, with some manual fixes.

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

This reverts commit b481cd51.

This revision adds two new classes, RewriterBase and IRRewriter. RewriterBase is a new shared base class between IRRewriter and PatternRewriter. PatternRewriter will continue to be the base class used to perform rewrites within a rewrite pattern. IRRewriter on the other hand, is a new class that allows for tracking IR rewrites from outside of a rewrite pattern. In this revision all of the old API from PatternRewriter is moved to RewriterBase, but the distinction between IRRewriter and PatternRewriter is kept on the chance that a necessary API divergence happens in the future.

Currently if you want to have some utility that transforms a piece of IR and share it between pattern and non-pattern code, you have to duplicate it. This revision enables the creation of utilities that can be invoked from rewrite patterns and normal transformation code:

```c++
void someSharedUtility(RewriterBase &rewriter, ...) {
  // Some interesting IR mutation here.
}

// Some RewritePattern
LogicalResult MyPattern::matchAndRewrite(Operation *op, PatternRewriter &rewriter) {
  ...
  someSharedUtility(rewriter, ...);
  ...
}

// Some Pass
void MyPass::runOnOperation() {
  ...
  IRRewriter rewriter(...);
  someSharedUtility(rewriter, ...);
}
```

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

Add description and dependencies.

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

Sample re-annotation is required in LTO time to achieve a reasonable post-inline profile quality. However, we have seen that such LTO-time re-annotation degrades profile quality. This is mainly caused by preLTO code duplication that is done by passes such as loop unrolling, jump threading, indirect call promotion etc, where samples corresponding to a source location are aggregated multiple times due to the duplicates. In this change we are introducing a concept of distribution factor for pseudo probes so that samples can be distributed for duplicated probes scaled by a factor. We hope that optimizations duplicating code well-maintain the branch frequency information (BFI) based on which probe distribution factors are calculated. Distribution factors are updated at the end of preLTO pipeline to reflect an estimated portion of the real execution count.

This change also introduces a pseudo probe verifier that can be run after each IR passes to detect duplicated pseudo probes.

A saturated distribution factor stands for 1.0. A pesudo probe will carry a factor with the value ranged from 0.0 to 1.0. A 64-bit integral distribution factor field that represents [0.0, 1.0] is associated to each block probe. Unfortunately this cannot be done for callsite probes due to the size limitation of a 32-bit Dwarf discriminator. A 7-bit distribution factor is used instead.

Changes are also needed to the sample profile inliner to deal with prorated callsite counts. Call sites duplicated by PreLTO passes, when later on inlined in LTO time, should have the callees’s probe prorated based on the Prelink-computed distribution factors. The distribution factors should also be taken into account when computing hotness for inline candidates. Also, Indirect call promotion results in multiple callisites. The original samples should be distributed across them. This is fixed by adjusting the callisites' distribution factors.

Reviewed By: wmi

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

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

Previously, operator== would consider the actual equality of the pairs
(lhs.Value, lhs.State) == (rhs.Value, rhs.State). However, if an invalid
cost was involved in a call to operator<, only the state would be
compared. Thus, it was not the case that ({2, Invalid} < {3, Invalid} ||
{2, Invalid} > {3, Invalid} || {2, Invalid} == {3, Invalid}).

This patch implements a true total ordering, where cost state is
considered first, then value. While it's not really imporant that
{2, Invalid} be considered to be less than {3, Invalid}, it's not a
problem either. This patch also implements operator== in terms of
operator<, so the two definitions will be kept in sync.

Reviewed By: sdesmalen

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

Implement IEEE_SUPPORT_DATATYPE() and other inquiry intrinisic
functions from the intrinsic module IEEE_ARITHMETIC, folding all of
their results to .TRUE.

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

UBOUND() is not allowed on the last dimension of an
assumed-size array dummy argument.

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

The MLIR Async runtime uses different namespacing for the header file,
and the definitions of its C API. The header file places the extern "C"
functions inside namespace mlir::runtime, and the definitions are not
in a namespace. This causes issues in cl.exe. It treats the declaration
and definition as different, and thus does not apply dllexport to the
definition, which leads to the mlir_async_runtime.dll containing no
definitions, and the mlir_async_runtime.lib not being generated.

This patch moves the namespace to cover the definitions, and thus
generates the dll correctly on Windows with cl.exe.

This was tested with Visual Studio C++ 19.28.29336.

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

Add the necessary bits to CMakeLists to make it possible to configure
MLIR against installed LLVM, and build it with minimal need for LLVM
source tree.  The latter is only necessary to run unittests, and if it
is missing then unittests are skipped with a warning.

This change includes the necessary changes to tests, in particular
adding some missing substitutions and defining missing variables
for lit.site.cfg.py substitution.

Reviewed By: stephenneuendorffer

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



Co-authored-by: Isuru Fernando <isuruf@gmail.com>

The __resume function trips up LLVM's 'X86 DAG->DAG Instruction Selection' unless optimizations are disabled.

Only adding the __resume function when it's needed allows lowering through AsyncToLLVM and LLVM without '-O0' as long as the coroutine functionality is not used.

Reviewed By: ezhulenev

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

LLVM_TARGETS_TO_BUILD accepts both "host" or "Native" for auto-selecting
the target from the environment. However the way "Native" was plumbed
would lead to the JIT environment being disabled. This patch is making
"Native" works just as "host".

Reviewed By: rnk

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

Due to a clerical error, the sdiv operation was mapping to vdivu and
udiv to vdiv, when the opposite mapping is the correct one.

Reviewed By: craig.topper

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

It will allow to perform additional manipulation with the newly created Operation.
For example, custom attributes propagation/changes.

Reviewed By: ftynse

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

Include the types into the error message.

Reviewed By: ftynse

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

Reviewed By: rriddle

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

Reviewed By: mehdi_amini

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

This makes the generated code independent from actual namespace of its users.

Reviewed By: rriddle

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

[RISCV] Use a ComplexPattern to merge isel patterns for vector load/store with GPR and FrameIndex addresses.

This reduces the isel table size by about 3000 bytes.

Reviewed By: frasercrmck

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

The number of iterations calculation was failing in some cases with more
than two collpased loops. Now the LoopIterationSpace selected matches
InitDependOnLC and CondDependOnLC.

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

Add per-reloc-type attribute bits and migrate code from per-target file into target independent code, driven by reloc attributes.

Many cleanups

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

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

The option catches incompatibility between `R_*_IRELATIVE` and DT_TEXTREL/DF_TEXTREL
before glibc 2.29. Newer glibc versions are more common nowadays and I don't
think this option has ever been used. Diagnosing this problem is also
straightforward by reading the stack trace.

As titled.

Reviewed By: wmi, wenlei

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

Without `-dwarf-version`, llvm-mc uses the default `MCContext::DwarfVersion` 4.

Without `-gdwarf-N`, Clang cc1as uses `clang::driver::ToolChain::GetDefaultDwarfVersion`
which is 4 on many toolchains. Note: `clang -c` can synthesize .debug_info without -g.

There is currently a MCParser warning upon `.file 0` and MCParser errors upon
`.loc 0` if the DWARF version is less than 5. This causes friction to the
following usage:

```
clang -S -g -gdwarf-5 a.c

// MC warning due to .file 0, MC error due to .loc 0
clang -c a.s
llvm-mc -filetype=obj a.s
```

My idea is that we can just upgrade `MCContext::DwarfVersion` to 5 upon
`.file 0` to make the above commands work.

The downside is that for an explicit version `clang -c -gdwarf-4 a.s`, it can be
argued that the new behavior drops the probably intended diagnostic. I think the
downside is small because in most cases DWARF version for an assembly action
should either match the original compile action or be omitted.

Ongoing discussion taking a similar action for GNU as: https://sourceware.org/pipermail/binutils/2021-January/114980.html

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