This is getting reverted and relanded a lot, breaking the build each time. Differential Revision: https://reviews.llvm.org/D114043
We need to avoid directly processing the Bazel config in LLVM's copy of google/benchmark, which was moved in https://github.com/llvm/llvm-project/commit/1ee32055ea. Differential Revision: https://reviews.llvm.org/D114014
This feature checks that headers included by a file are provided by a header exported by one of the direct dependencies of the build rule in which it is contained. It ensures that appropriate layering (a goal of the LLVM project) is preserved. So far, I'm only adding this to MLIR because we've had it turned on internally since the beginning, so MLIR is already layering clean. It would be nice to also enable it for LLVM, but that requires some additional cleanup. Reviewed By: jpienaar Differential Revision: https://reviews.llvm.org/D113952
We noticed that the library structure causes link ordering problems in Google's internal build. However, we don't think the problem is specific to Google's build, it probably can be reproduced anywhere with the right library structure. In general splitting the Python bindings from their dependencies (the C API targets) creates the possibility that the two libraries might end up in the wrong order on the linker command line. We can avoid this problem happening by reverting the structure of the MLIRBindingsPythonCore to represent its dependencies in the usual way, rather than composing an incomplete `MLIRBindingsPythonCoreNoCAPI` target and their CAPI dependencies. It was probably a mistake to rewrite this particular `cc_library()` rule in terms of the two, since nothing guarantees that the two will be correctly ordered by the linker when both are being linked into the same binary, and it was only an incidental "cleanup" done in passing. Otherwise the previous PR (D113565) is fine, since that was about the case where both are being built into two separate shared libraries. It just shouldn't have made this (unrelated) change. Reviewed By: GMNGeoffrey Differential Revision: https://reviews.llvm.org/D113773
The remaining dialects will be decoupled from ComprehensiveBufferize in separate commits. Differential Revision: https://reviews.llvm.org/D113459
This allows clients to build, e.g., the Python bindings against the C API headers, without including the C API implementations. This is useful when distributing software as multiple shared libraries. Reviewed By: GMNGeoffrey Differential Revision: https://reviews.llvm.org/D113565
* Move "linalg.inplaceable" attr name literals to BufferizableOpInterface. * Use `memref.copy` by default. Override to `linalg.copy` in ComprehensiveBufferizePass. These are the last remaining code dependencies on Linalg in Comprehensive Bufferize. The next commit will make ComprehensiveBufferize independent of the Linalg dialect. Differential Revision: https://reviews.llvm.org/D113457
This revision adds an implementation of 2-D vector.transpose for 4x8 and 8x8 for AVX2 and surfaces it to the Linalg level of control. Reviewed By: dcaballe Differential Revision: https://reviews.llvm.org/D113347
Move helper functions for traversing reverse use-def chains. These are useful for implementing custom optimizations (e.g., custom InitTensorOp eliminations). Also move over the AllocationCallbacks struct. This is in preparation for decoupling ComprehensiveBufferize from various dialects. Differential Revision: https://reviews.llvm.org/D113386
This structure is necessary to be able to use AttrDef as arguments on operations. Differential Revision: https://reviews.llvm.org/D113327