Progress:
In progressChanges

Summary

  1. [mlir][shape] Make conversion passes more consistent. (details)
  2. [EHStreamer] Simplify sharedTypeIDs with std::mismatch (details)
  3. [CVP] Allow two transforms in one invocation (details)
  4. Guard `find_library(tensorflow_c_api ...)` by checking for TENSORFLOW_C_LIB_PATH to be set by the user (details)
Commit a975be0e00a12fdf09ffc9127825321c79813f33 by silvasean
[mlir][shape] Make conversion passes more consistent.

- use select-ops to make the lowering simpler
- change style of FileCheck variables names to be consistent
- change some variable names in the code to be more explicit

Differential Revision: https://reviews.llvm.org/D88258
The file was modifiedmlir/test/Conversion/ShapeToStandard/shape-to-standard.mlir (diff)
The file was modifiedmlir/lib/Conversion/ShapeToStandard/ShapeToStandard.cpp (diff)
The file was modifiedmlir/lib/Conversion/ShapeToStandard/ConvertShapeConstraints.cpp (diff)
The file was modifiedmlir/test/Conversion/ShapeToStandard/convert-shape-constraints.mlir (diff)
Commit bd08a87cfede308f040d79b45245213afd87959a by i
[EHStreamer] Simplify sharedTypeIDs with std::mismatch

(Note that EMStreamer.cpp is largely under tested. The only test checking the prefix sharing is CodeGen/WebAssembly/eh-lsda.ll)
The file was modifiedllvm/lib/CodeGen/AsmPrinter/EHStreamer.cpp (diff)
Commit e46d74b58922a427562552464d798448520e4928 by listmail
[CVP] Allow two transforms in one invocation

For a call site which had both constant deopt operands and nonnull arguments, we were missing the opportunity to recognize the later by bailing early.

This is somewhat of a speculative fix.  Months ago, I'd had a private report of performance and compile time regressions from the deopt operand folding.  I never received a test case.  However, the only possibility I see was that after that change CVP missed the nonnull fold, and we end up with a pass ordering/missed simplification issue.  So, since it's a real issue, fix it and hope.
The file was modifiedllvm/lib/Transforms/Scalar/CorrelatedValuePropagation.cpp (diff)
The file was modifiedllvm/test/Transforms/CorrelatedValuePropagation/deopt.ll (diff)
Commit e72d792c147ee506e337401e20c0f23042cc43fe by joker.eph
Guard `find_library(tensorflow_c_api ...)` by checking for TENSORFLOW_C_LIB_PATH to be set by the user

Also have CMake fails if the user provides a TENSORFLOW_C_LIB_PATH but
we can't find TensorFlow at this path.

At the moment the CMake script tries to figure if TensorFlow is
available on the system and enables support for it. This is in general
not desirable to customize build features this way and instead it is
preferable to let the user opt-in explicitly into the features they want
to enable. This is in line with other optional external dependencies
like Z3.
There are a few reasons to this but amongst others:
- reproducibility: making features "magically" enabled based on whether
  we find a package on the system or not makes it harder to handle bug
  reports from users.
- user control: they can't have TensorFlow on the system and build LLVM
  without TensorFlow right now. They also would suddenly distribute LLVM
  with a different set of features unknowingly just because their build
  machine environment would change subtly.

Right now this is motivated by a user reporting build failures on their system:

.../mesa-git/llvm-git/src/llvm-project/llvm/lib/Analysis/TFUtils.cpp:23:10: fatal error: tensorflow/c/c_api.h: No such file or directory
   23 | #include "tensorflow/c/c_api.h"
      |          ^~~~~~

It looks like we detected TensorFlow at configure time but couldn't set all the paths correctly.

Differential Revision: https://reviews.llvm.org/D88371
The file was modifiedllvm/CMakeLists.txt (diff)