Fix xnn linkage issue when building wheels #7173
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/7173
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 10a1288 with merge base d89d3e7 ( This comment was automatically generated by Dr. CI and updates every 15 minutes. |
facebook-github-bot
added
the
CLA Signed
|
I'm adding |
There was a problem hiding this comment.
M1 build looks ok now https://github.com/pytorch/executorch/actions/runs/12164871356
| list(APPEND _dep_libs xnnpack_backend XNNPACK) | ||
| # need to explicitly specify XNNPACK and microkernels-prod | ||
| # here otherwise uses XNNPACK and microkernel-prod symbols from libtorch_cpu | ||
| list(APPEND _dep_libs xnnpack_backend XNNPACK microkernels-prod) |
There was a problem hiding this comment.
surprised it didn't cause more problems before TBH
|
Curious how it is related to the broken |
|
@mcr229 has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Resolving the following issue:
#7019
XNNPACK has split its targets to XNNPACK (core orchestration of kernels) and microkernels-prod to separate static libraries. In upstream PyTorch we updated to this change, and had to make changes throughout the PyTorch CMake to install and link both XNNPACK and microkernels-prod.
Originally I had thought the issue stemmed from a mistake in PyTorch in which we weren't correctly linking microkernels-prod to torch_cpu, which when linked with portable pybindings was causing missing symbol issues related to ADRP. This led me to spend a lot of time messing with the pytorch cmake, rebuilding the wheels locally, pip installing them and trying to rebuild the executorch wheels. However, after much troubleshooting, I realized that the issue wasn't that the microkernels-prod static library was missing, but rather because it was there. This was likely causing problems duplicate linking problems with the microkernels-prod from our xnnpack_backend target as we were looking for microkernel function pointers in torch_cpu.
Previously we explicitly linked XNNPACK along with the xnnpack_backend in order to avoid using the XNNPACK symbols libtorch_cpu.dylib(from pytorch). Since Executorch and Pytorch now have the change of split targets between XNNPACK and microkernels-prod, we also have to explicitly link microkernel-prod we built for the xnnpack_backend to avoid using the static library from upstream torch_cpu. This is likely what caused the
ld: invalid use of ADRP in ...because the function pointer to the ukernel (in microkernel-prod) was pointing to the instance of torch_cpu.I tested it out by finally rebuilding the wheels with the latest torch nightly, and it was able to succeed.