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

SETLT and SETGT can use `{v}pcmpgt` directly whereas the other SETCC
variants require some other instructions as well. On AVX512, which has
vector comparisons for all SETCC variants, this can still be
preferable if the destination is a vector. And if the destination is a
mask, its the same performance.

The transform for unsigned SETCC takes place if we know from
`KnownBits` that LHS/RHS have the same sign.

The transform for LE/GE -> LT/GT takes place if LHS/RHS is constant
and we can inc/dec all elements in the operand without overflowing
(both signed and unsigned).

Alive2 Links (on i8 so they don't timeout):
sge_s:   https://alive2.llvm.org/ce/z/rMPt9_
sge_s_2: https://alive2.llvm.org/ce/z/G74Mhs
sge_u:   https://alive2.llvm.org/ce/z/PTWARM
sge_u_2: https://alive2.llvm.org/ce/z/L9dsNn
sgt_s:   https://alive2.llvm.org/ce/z/q2CHEK
sgt_u:   https://alive2.llvm.org/ce/z/YPLnZ8
sle_s:   https://alive2.llvm.org/ce/z/HyYhQ_
sle_s_2: https://alive2.llvm.org/ce/z/ck6NkT
sle_u:   https://alive2.llvm.org/ce/z/tyF_wN
sle_u_2: https://alive2.llvm.org/ce/z/et8t98
slt_s:   https://alive2.llvm.org/ce/z/oCP43b
slt_u:   https://alive2.llvm.org/ce/z/EpLLPx
uge_s:   https://alive2.llvm.org/ce/z/rqSDwi
uge_s_2: https://alive2.llvm.org/ce/z/67UTXu
uge_u:   https://alive2.llvm.org/ce/z/yBNG9C
uge_u_2: https://alive2.llvm.org/ce/z/UhHYc_
ugt_s:   https://alive2.llvm.org/ce/z/tY9va4
ugt_u:   https://alive2.llvm.org/ce/z/F9zeAT
ule_s:   https://alive2.llvm.org/ce/z/1MNgka
ule_s_2: https://alive2.llvm.org/ce/z/oiS7Ls
ule_u:   https://alive2.llvm.org/ce/z/8DveC3
ule_u_2: https://alive2.llvm.org/ce/z/jGp2M7
ult_s:   https://alive2.llvm.org/ce/z/chzfwP
ult_u:   https://alive2.llvm.org/ce/z/Jj_JYu

Reviewed By: RKSimon

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

This revision performs a bunch of cleanups and tracks free-flowing IR mutations.
APIs are systematized around RewriterBase and relevant debug messages are added.
Deliberate use of OpBuilder::InsertionGuard is added where needed.

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

While some blake3 symbols are already prefixed, a number of symbols with hidden visibility have been left without an `llvm_` prefix.  This results in symbol collisions when statically linking llvm into a binary that also uses the external blake3 library.

Reviewed By: akyrtzi, MaskRay

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

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

Follow-up to the equivalent change for scalars:
D143505 / 83ba349a

Coverage for extension of functionality from D143505.

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

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

This reverts commit cb5f2393.

Reviewed By: philnik, #libc

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

There are 2 issues here:

1. In the default LLVM FP environment (regular FP math instructions),
   SNaN is some flavor of "don't care" which we will nail down in
   D143074, so this is just a quality-of-implementation improvement
   for default FP.
2. In the constrained FP environment (constrained intrinsics), SNaN
   must not propagate through a math operation; it has to be quieted
   according to IEEE-754 spec. That is independent of exception
   handling mode, so the current behavior is a miscompile.

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

Adding baseline test based on D87479, so we know
current state and limitations of a potential fix.

Not all float types are supported in SPIR-V.

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

Reviewed By: antiagainst

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

06d9bf5e (https://reviews.llvm.org/D143431)
did a large restructuring of how the import library is created;
previously, a second step to tweak the import library was only
done for MSVC style targets, but after this commit, that logic
was applied for mingw targets too.

Since LIBOMP_GENERATED_IMP_LIB_FILENAME and LIBOMP_IMP_LIB_FILE
are equal on mingw targets (both are "libomp.dll.a", while they
are "libomp.dll.lib" and "libomp.lib" for MSVC targets), this caused
a conflict, with errors like this:

  ninja: error: build.ninja:875: multiple rules generate runtime/src/libomp.dll.a [-w dupbuild=err]

Skip the logic with a second step to recreate the import library
for mingw targets. The MSVC specific logic for this relies on
running the static archiver with CMAKE_LINK_DEF_FILE_FLAG, which
with MS lib.exe (and llvm-lib) ignore the input object files and
just generates an import library - but mingw style tools don't
support this mode of operation. (By attemptinig the same, mingw tools
would generate a static library with the def file as one member.)
With mingw tools, the same can be achieved by invoking the dlltool
executable instead.

Instead of adding alternative logic for invoking dlltool, just skip
the second import library step, since neither GNU nor LLVM mingw
tools actually generate import libraries that link by ordinal - so
there's no need for a second import library.

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

This reverts commit ed3e3ee9.