[PATCH] D61446: Generalize the pass registration mechanism used by Polly to any third-party tool

serge via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon May 6 04:42:41 PDT 2019


serge-sans-paille marked 5 inline comments as done.
serge-sans-paille added inline comments.


================
Comment at: CMakeLists.txt:512
+    string(TOLOWER ${llvm_extension_lib} llvm_extension_dir)
+    include(${LLVM_MAIN_SRC_DIR}/tools/${llvm_extension_dir}/cmake/extension.cmake OPTIONAL)
+endforeach()
----------------
mehdi_amini wrote:
> We shouldn't hardcode anything with respect to the "tools" folder in llvm. I see that your patch is setup like if clang is in llvm/tools, but the current recommended setup for laying out the directories for subproject is "side by side" in the monorepo: https://github.com/llvm/llvm-project/
I've tried to make it compatible with llvm-project while maintaining current status wrt. `tools`


================
Comment at: CMakeLists.txt:521
+endforeach()
+file(APPEND "${CMAKE_BINARY_DIR}/include/llvm/Support/Extension.def" "#undef HANDLE_EXTENSION\n")
 
----------------
mehdi_amini wrote:
> Is this file gonna be re-written for each re-execution of CMake?
> Will this trigger more recompilation than needed?
> If so what can be done about this? Can we generate a copy and replace the final one only if it differs in content? Can we make re-writing the file a rule based on actual dependencies (a target depending on the content of `LLVM_EXTENSION_LIBS` changing)?
Using as shA256 is not 100% bullet proof but should be ok, right?


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D61446/new/

https://reviews.llvm.org/D61446





More information about the llvm-commits mailing list