FailedChanges

Summary

  1. [InstSimplify] Fold min/max based on dominating condition (details)
  2. [InstCombine] Fold abs with dominating condition (details)
  3. [SCEV] Recognize min/max intrinsics (details)
  4. Thread safety analysis: Consider global variables in scope (details)
  5. Thread safety analysis: ValueDecl in Project is non-null (details)
  6. [InstCombine] Add tests for known negative abs intrinsic (NFC) (details)
Commit 73104b0751a1c1dd499550bf44e47d29882fbb32 by nikita.ppv
[InstSimplify] Fold min/max based on dominating condition

If we have a dominating condition that x >= y, then umax(x, y) is x,
etc. I'm doing this in InstSimplify as the corresponding transform
for the select form is also done there.

Differential Revision: https://reviews.llvm.org/D87168
The file was modifiedllvm/test/Transforms/InstSimplify/maxmin_intrinsics.ll
The file was modifiedllvm/lib/Analysis/InstructionSimplify.cpp
Commit 4892d3a1983b0fae83e9476d8cec1d139da7eae0 by nikita.ppv
[InstCombine] Fold abs with dominating condition

Similar to D87168, but for abs. If we have a dominating x >= 0
condition, then we know that abs(x) is x. This fold is in
InstCombine, because we need to create a sub instruction for
the x < 0 case.

Differential Revision: https://reviews.llvm.org/D87184
The file was modifiedllvm/lib/Transforms/InstCombine/InstCombineCalls.cpp
The file was modifiedllvm/test/Transforms/InstCombine/abs-intrinsic.ll
Commit ac87480bd8beef0a4e93981e38df2c21652e1393 by nikita.ppv
[SCEV] Recognize min/max intrinsics

Recognize umin/umax/smin/smax intrinsics and convert them to the
already existing SCEV nodes of the same name.

In the future we'll want SCEVExpander to also produce the intrinsics,
but we're not ready for that yet.

Differential Revision: https://reviews.llvm.org/D87160
The file was modifiedllvm/lib/Analysis/ScalarEvolution.cpp
The file was modifiedllvm/test/Analysis/ScalarEvolution/minmax-intrinsics.ll
Commit 9dcc82f34ea9b623d82d2577b93aaf67d36dabd2 by aaronpuchert
Thread safety analysis: Consider global variables in scope

Instead of just mutex members we also consider mutex globals.
Unsurprisingly they are always in scope. Now the paper [1] says that

> The scope of a class member is assumed to be its enclosing class,
> while the scope of a global variable is the translation unit in
> which it is defined.

But I don't think we should limit this to TUs where a definition is
available - a declaration is enough to acquire the mutex, and if a mutex
is really limited in scope to a translation unit, it should probably be
only declared there.

[1] https://static.googleusercontent.com/media/research.google.com/en/us/pubs/archive/42958.pdf

Fixes PR46354.

Reviewed By: aaron.ballman

Differential Revision: https://reviews.llvm.org/D84604
The file was modifiedclang/test/SemaCXX/warn-thread-safety-analysis.cpp
The file was modifiedclang/test/SemaCXX/warn-thread-safety-negative.cpp
The file was modifiedclang/lib/Analysis/ThreadSafety.cpp
Commit b2ce79ef66157dd752e3864ece57915e23a73f5d by aaronpuchert
Thread safety analysis: ValueDecl in Project is non-null

The constructor asserts that, use it in the ThreadSafetyAnalyzer.
Also note that the result of a cast<> cannot be null.
The file was modifiedclang/lib/Analysis/ThreadSafetyCommon.cpp
The file was modifiedclang/lib/Analysis/ThreadSafety.cpp
Commit 5ad6552a836ef759ff8a96ffec333aacabb8dc36 by nikita.ppv
[InstCombine] Add tests for known negative abs intrinsic (NFC)

And duplicate tests for known non-negative from InstSimplify.
The file was modifiedllvm/test/Transforms/InstCombine/abs-intrinsic.ll