[MLIR] Do not link mlir-cpu-runner with X86 libs

[clementval]

Summary

The three libs where recently added to the mlir-cpu-runner's CMakeLists.txt file. This prevent the runner to compile on other platform (e.g. Power in my case)

[stephenneuendorffer]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

I'm curious how this successfully builds on Power. I would have thought that linking with the Power target would be necessary. My thinking here was that this should link against whatever the native target is., which I believe is all abstracted behind the Jit interfaces.

[clementval]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

On my Power system I can successfully use the miler-cpu-runner without linking with those target libs. Since I wasn't sure for an X86 target I just made it conditional but maybe it is not required at all and could be removed?

[stephenneuendorffer]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

I think it succeeds because of this in MLIRExecutionEngine:
llvm_map_components_to_libnames(outlibs "nativecodegen" "IPO")

[clementval]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

That's probably it. Then we should remove the X86 specific ones here. They should be added already in the ExecutionEngine right?

[stephenneuendorffer]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

I think so, as long as it works with BUILD_SHARED_LIBS=on.

[mehdi_amini]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

We shouldn't specify a particular backend here. If just removing does not work, we should find something generic like for the MLIRExecutionEngine.

[clementval]

mlir/tools/mlir-cpu-runner/CMakeLists.txt

21

@stephenneuendorffer @mehdi_amini I have tested with BUILD_SHARED_LIBS=on with this updated patch and the milr-cpu-runner works just fine.

Not related to this patch but the for the MLIRMlirOptMain target I had to add MLIRQuantizerTransforms, MLIRTestIR, MLIRTestPass, MLIRTestTransforms, MLIRSPIRVTestPasses in LIB_LIBS as well as ${dialect_libs} and ${conversion_libs} in the target_link_libraries(MLIRMlirOptMain to avoid linking problem.

[stephenneuendorffer]

Thanks! (and yes, I'm somewhat aware that MlirOptMain is broken. I think it needs basically the same dependencies as mlir-opt. I have a patch to fix it floating around somewhere).

[clementval]

In D75916#1917077, @stephenneuendorffer wrote:

Thanks! (and yes, I'm somewhat aware that MlirOptMain is broken. I think it needs basically the same dependencies as mlir-opt. I have a patch to fix it floating around somewhere).

Thanks for the review! Can you push the patch? I do not have commit rights.

[clementval]

@stephenneuendorffer Thanks for pushing this. The attribution was not reflected correctly on the commit. It doesn't really matter for this small patch anyway.

[mehdi_amini]

@clementval : if you use arc then things like credit attribution works out-of-the-box (and we get CI testing on the revision on Phabricator).

[clementval]

In D75916#1917845, @mehdi_amini wrote:

@clementval : if you use arc then things like credit attribution works out-of-the-box (and we get CI testing on the revision on Phabricator).

@mehdi_amini Good to know. Will do that for the next patch.

[stephenneuendorffer]

@clementval Oops, sorry about that. I'll watch out for that in the future. I definitely want to make sure that the attribution is correct!

mlir/tools/mlir-cpu-runner/CMakeLists.txt

target_link_libraries(mlir-cpu-runner PRIVATE
   MLIRIR
   MLIRJitRunner
   MLIRLLVMIR
   MLIRParser
   MLIRTargetLLVMIR
   MLIRSupport
   LLVMCore
   LLVMSupport
-  LLVMX86CodeGen
-  LLVMX86Desc
-  LLVMX86Info
   )