Support for masking static shapes was already implemented in the past
but not enabled so this patch is just removing a pre-condition check and
adding some tests with static shapes.

Reviewed By: ThomasRaoux

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

This patch adds support for masked vector.gather ops using the
vector.mask representation. It includes the implementation of the
MaskableOpInterface, Linalg vectorizer support and lowering to LLVM.

Reviewed By: ThomasRaoux

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

This patch adds support for masking vector.contract ops with the
vector.mask approach. This also includes the lowering of vector.contract
through the vector.outerproduct path to LLVM. For now, this only adds
support for one of the many potential flavors of
vector.contract/vector.outerproduct but unsupported cases will fail
gratefully.

Reviewed By: ThomasRaoux

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

This patch adds the conversion patterns to lower masked reduction
operations to the corresponding vp intrinsics in LLVM.

Reviewed By: ftynse

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

Following recent changes to remove non-core features of the legacy PM/optimization pipeline.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716

/home/jiefu/llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/Sparsification.cpp:279:33: error: comparison of integers of different signs: 'int64_t' (aka 'long') and 'const mlir::sparse_tensor::Level' (aka 'const unsigned long') [-Werror,-Wsign-compare]
    assert(env.op().getRank(&t) == lvlRank);
           ~~~~~~~~~~~~~~~~~~~~ ^  ~~~~~~~
/usr/include/assert.h:93:27: note: expanded from macro 'assert'
     (static_cast <bool> (expr)                                         \
                          ^~~~
1 error generated.

/home/jiefu/llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorRewriting.cpp:788:29: error: comparison of integers of different signs: 'int64_t' (aka 'long') and 'const mlir::sparse_tensor::Dimension' (aka 'const unsigned long') [-Werror,-Wsign-compare]
    assert(srcRTT.getRank() == dimRank);
           ~~~~~~~~~~~~~~~~ ^  ~~~~~~~
/usr/include/assert.h:93:27: note: expanded from macro 'assert'
     (static_cast <bool> (expr)                                         \
                          ^~~~
/home/jiefu/llvm-project/mlir/lib/Dialect/SparseTensor/Transforms/SparseTensorRewriting.cpp:810:31: error: comparison of integers of different signs: 'int64_t' (aka 'long') and 'const mlir::sparse_tensor::Dimension' (aka 'const unsigned long') [-Werror,-Wsign-compare]
      assert(srcRTT.getRank() == dimRank);
             ~~~~~~~~~~~~~~~~ ^  ~~~~~~~
/usr/include/assert.h:93:27: note: expanded from macro 'assert'
     (static_cast <bool> (expr)                                         \
                          ^~~~
2 errors generated.

RISC-V vector instruction has register overlapping constraint for certain
instructions, and will cause illegal instruction trap if violated, we use
early clobber to model this constraint, but it can't prevent register allocator
allocated same or overlapped if the input register is undef value, so convert
IMPLICIT_DEF to temporary pseudo could prevent that happen, it's not best way
to resolve this. Ideally we should model the constraint right, but before we
model the constraint right, it's the approach to prevent that happen.

See also: https://github.com/llvm/llvm-project/issues/50157

Reviewed By: craig.topper

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

Reviewed By: kito-cheng

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

Required in https://reviews.llvm.org/D137526. And it is indeed odd that
LexTest depends on ClangFrontend.

The existing Create method took a path to the ORC runtime and created a
StaticLibraryDefinitionGenerator for it. The new overload takes a
std::unique_ptr<DefinitionGenerator> directly instead. This provides more
flexibility when constructing MachOPlatforms. E.g. The runtime archive can be
embedded in a special section in the ORC controller executable or library,
rather than being on-disk.

This is the ELFNixPlatform equivalent of the MachOPlatform change in
be2fc577.

This change adds a new `SparseTensorType` class for making the "dim" vs "lvl" distinction more overt, and for abstracting over the differences between sparse-tensors and dense-tensors.  In addition, this change also adds new type aliases `Dimension`, `Level`, and `FieldIndex` to make code more self-documenting.

Although the diff is very large, the majority of the changes are mechanical in nature (e.g., changing types to use the new aliases, updating variable names to match, etc).  Along the way I also made many variables `const` when they could be; the majority of which required only adding the keyword.  A few places had conditional definitions of these variables, requiring actual code changes; however, that was only done when the overall change was extremely local and easy to extract.  All these changes are included in the current patch only because it would be too onerous to split them off into a separate patch.

Reviewed By: aartbik

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

Add a test to ensure that the clang-scan-deps won't crash due to the
unexpected use of clang modules.

UnpackOp Converter used to create reallocOp unconditionally, but it might cause issue when the requested memory size is smaller than the actually storage.

Reviewed By: aartbik

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

For the pattern `(zext i1 X) + (sext i1 Y)`, the constant range is [-1, 1].
We can simplify the pattern by logical operations. Like:

```
    (zext i1 X) + (sext i1 Y) == -1 -->  ~X & Y
    (zext i1 X) + (sext i1 Y) == 0  --> ~(X ^ Y)
    (zext i1 X) + (sext i1 Y) == 1 --> X & ~Y
```
And other predicates can the combination of these results:

```
    (zext i1 X) + (sext i1 Y)) != -1 --> X | ~Y
    (zext i1 X) + (sext i1 Y)) s> -1 --> X | ~Y
    (zext i1 X) + (sext i1 Y)) u< -1 --> X | ~Y
    (zext i1 X) + (sext i1 Y)) s> 0 --> X & ~Y
    (zext i1 X) + (sext i1 Y)) s< 0 --> ~X & Y
    (zext i1 X) + (sext i1 Y)) != 1 --> ~X | Y
    (zext i1 X) + (sext i1 Y)) s< 1 --> ~X | Y
    (zext i1 X) + (sext i1 Y)) u> 1 --> ~X & Y
```

All alive proofs:
https://alive2.llvm.org/ce/z/KmgDpF
https://alive2.llvm.org/ce/z/fLwWa9
https://alive2.llvm.org/ce/z/ZKQn2P

Fix: https://github.com/llvm/llvm-project/issues/59666

Reviewed By: spatel

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

During the SeparateConstOffsetFromGEP pass, a - b and b - a will be
considered equivalent in some instances.

An example- the IR contains:

  BB1:
      %add = add %a, 511
      br label %BB2
  BB2:
      %sub2 = sub %b,  %a
      br label %BB3
  BB3:
      %sub1 = sub %add, %b
      %gep = getelementptr float, ptr %p, %sub1

Step 1 in the SeparateConstOffsetFromGEP pass, after split constant index:

  BB1:
      %add = add %a, 511
      br label %BB2
  BB2:
      %sub2 = sub %b,  %a
      br label %BB3
  BB3:
      %sub.t = sub %a, %b
      %gep.base = getelementptr float, ptr %p, %sub.t
      %gep = getelementptr float, ptr %gep.base, 511

Step 2, after reuniteExts:

  BB1:
      br label %BB2
  BB2:
      %sub2 = sub %b,  %a
      br label %BB3
  BB3:
      %gep.base = getelementptr float, ptr %p, %sub2
      %gep = getelementptr float, ptr %gep.base, 511

Obviously, reuniteExts treated a - b and b - a as equivalent.
This patch fixes that.

Reviewed By: nikic, spatel

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

We need such a flag to check whether the transformation is correct if
LowerGEP was enabled.

Reviewed By: nikic, arsenm, spatel

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

Depends on D143657

Reviewed By: craig.topper

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

In file included from /data/llvm-project/mlir/lib/Conversion/VectorToGPU/VectorToGPU.cpp:13:
/data/llvm-project/mlir/include/mlir/Conversion/VectorToGPU/VectorToGPU.h:15:1: error: class 'LogicalResult' was previously declared as a struct; this is valid, but may result in linker errors under the Microsoft C++ ABI [-Werror,-Wmismatched-tags]
class LogicalResult;
^
/data/llvm-project/mlir/include/mlir/Support/LogicalResult.h:26:22: note: previous use is here
struct [[nodiscard]] LogicalResult {
                     ^
/data/llvm-project/mlir/include/mlir/Conversion/VectorToGPU/VectorToGPU.h:15:1: note: did you mean struct here?
class LogicalResult;
^~~~~
struct

/data/llvm-project/mlir/lib/Conversion/VectorToGPU/VectorToGPU.cpp:724:5: error: ignoring return value of function declared with 'nodiscard' attribute [-Werror,-Wunused-result]
    rewriter.notifyMatchFailure(
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.

allocation ring buffer is allowed to be zero. Update the logic in the
test so that on the platform that disables it won't fail this case.

Reviewed By: fmayer

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

Following recent changes to remove non-core features of the legacy PM/optimization pipeline.

This CL adds the proper thread-safety annotations for most of the
functions and variables. However, given the restriction of the current
architecture, in some cases, we may not be able to use the annotations
easily. The followings are two exceptions,

1. enable()/disable(): Many structures in scudo are enabled/disabled by
   acquiring the lock in each instance. This makes those structure act
   like a `lock`. We can't mark those functions with ACQUIRE()/RELEASE()
   because that makes the entire allocator become another `lock`. In the
   end, that implies we need to *acquire* the `allocator` before each
   malloc et al. request. Therefore, adding a variable to tell the
   status of those structures may be a better way to cooperate with
   thread-safety annotation.

2. TSD/TSD shared/TSD exclusive: These three have simiar restrictions as
   mentioned above. In addition, they don't always need to be released
   if it's a thread local instance. However, thread-safety analysis
   doesn't support conditional branch. Which means we can't mark the
   proper annotations around the uses of TSDs. We may consider to make
   it consistent and which makes the code structure simpler.

This CL is supposed to introduce the annotations with the least code
refactoring. So only trivial thread safety issues will be addressed
here. For example, lacking of acquiring certain lock before accessing
certain variables will have the ScopedLock inserted. Other than that,
they are supposed to be done in the later changes.

Reviewed By: cferris

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

Ideally `addu16i.d` could be paired with `{ld,st}ptr` for faster memory
accesses with 32-bit-aligned offsets (it was designed for this purpose),
but it would require more work and the original use case (GP-relative
accesses) does not exist any more with the current LoongArch psABI.

It could still be used for accelerating additions of certain constants
though, which is what this patch intends to do.

Reviewed By: SixWeining, gonglingqin

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

Reviewed By: gonglingqin

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

Similar to issue fixed in D107155, some lit tests invoke `llvm-lto`,
`llvm-lto2` and `llvm-profdata` without going through the substitution
system. While the test runner correctly picks up these binaries from
the build directory, it doesn't print its absolute path. When copying
the invocations when reproducing test failures, this can result in
`command not found: llvm-lto` or other errors (caused by using wrong
version of the tool).

This patch adds these tools to the `tools` variable in
`clang/test/lit.cfg.py` which will then call add_tool_substitutions.

Reviewed By: dblaikie

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

Summary:

Reviewers:

Subscribers:

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

This can be beneficial if there is a fast `ABS` (For example with X86
`vpabs`) or if there is a dominating ABS(A) in the `DAG`.

Note `C` is constant so `ABS(C)` is just a constant.

Alive2 Links:
EQ: https://alive2.llvm.org/ce/z/829F-c
NE: https://alive2.llvm.org/ce/z/tsS8bU

Reviewed By: pengfei

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

Reviewed By: pengfei

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

Only if Abs(A) has one use, in which case the `(and/or (icmp eq/ne
A,Pow2), (icmp eq/ne A,-Pow2))` can be optimized in
`DAGCombiner::foldAndOrOfSETCC`.

Alive Links:
EQ: https://alive2.llvm.org/ce/z/gTxSgV
NE: https://alive2.llvm.org/ce/z/MUf57Y

Reviewed By: RKSimon

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

Add Transform for `(and/or (eq/ne A,Pow2),(eq/ne A,-Pow2))`->`(eq/ne (and (and A,Pow2),~(Pow2*2)), 0)`

In many instances this can be preferable if the `icmp` -> `i1` cannot be
done in one instruction (such as X86 for scalars).

At the moment guarded behind `TLI.isDesirableToCombineLogicOpOfSETCC`.

alive2 links:
https://alive2.llvm.org/ce/z/nLm5sN
https://alive2.llvm.org/ce/z/moEcyE

Reviewed By: RKSimon

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

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