-
Notifications
You must be signed in to change notification settings - Fork 359
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make flatcc cross-compile deterministic #4312
Conversation
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/4312
Note: Links to docs will display an error until the docs builds have been completed. ❌ 3 New FailuresAs of commit 796a634 with merge base 711ecec (): NEW FAILURES - The following jobs have failed:
This comment was automatically generated by Dr. CI and updates every 15 minutes. |
I'm sorry for the delay on this, I'm taking a look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What we really need to do is send a PR to the flatcc upstream project, adding a cmake option to put the binaries in a different location (outside of the source tree).
Another option could even be to recursively copy the flatcc tree under cmake-out and build it from there for the host tools.
sdk/CMakeLists.txt
Outdated
# Add the host project. We build this separately so that we can generate | ||
# headers on the host during the build, even if we're cross-compiling the | ||
# flatcc runtime to a different architecture. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please preserve this comment to help readers understand why this is built in a special way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Will do, thanks.
sdk/CMakeLists.txt
Outdated
COMMAND rm -f ${_etdump_schema_cleanup_paths} | ||
WORKING_DIRECTORY ${CMAKE_BINARY_DIR}/sdk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even when building ahead of time, the flatcc build will still put the host binaries in _etdump_schema_cleanup_paths
. If we don't delete those here, then we need to be sure that the cross-compiled binaries will always overwrite the host binaries.
Did you find that it was necessary to remove this rm -f
to make things work? Could we keep it to keep things a bit safer for the cross-compiled binaries?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it's a good idea, changed. Previously I thought we only link libraries in cross-compile stage, it might not be necessary to delete artifacts.
But to make sure the deletion really happens, VERBATIM
should be removed or quote marks will be added to the target which will make rm
fail.
I also think WORKING_DIRECTORY
could be removed since we do not build test executables.
Both approaches are good! Since I do encounter failure under current scenario, this is the fastest way I could come up with to resolve issue. |
3818cb0
to
455b6f8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for these changes. Can you also update the PR description with a "Test Plan:" section that describes how you tested that a) this fixes your problem, and b) it doesn't break things for non-cross-compiling use cases? (I added a placeholder Test Plan section to the PR description)
sdk/CMakeLists.txt
Outdated
add_custom_target( | ||
etdump_schema_generated | ||
DEPENDS ${_etdump_schema__outputs} | ||
) | ||
|
||
add_dependencies(etdump_schema etdump_schema_generated) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could these DEPENDS be directly on etdump_schema
instead of creating this extra target?
Up above we already say add_library(etdump_schema INTERFACE ${_etdump_schema__outputs})
-- is that enough to add the dependencies? Or maybe you could also add a DEPENDS section to that same add_library
?
If this custom_target is necessary, please arrange the code so that it's closer to the add_library(etdump_schema, ...)
, and add a comment explaining why these deps can't be added directly to the library target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it can. Thanks for the hint, that's much cleaner.
Thank you! This is much more straightforward now. I'll start the internal testing process. |
@dbort has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
sdk/CMakeLists.txt
Outdated
-DFLATCC_TEST=OFF -DFLATCC_REFLECTION=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON | ||
-B${CMAKE_BINARY_DIR}/_host_build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One last request: please wrap this to fit in 80 columns (to satisfy an internal lint checker), and please restore the comment that was here before.
-DFLATCC_TEST=OFF -DFLATCC_REFLECTION=OFF -DCMAKE_POSITION_INDEPENDENT_CODE=ON | |
-B${CMAKE_BINARY_DIR}/_host_build | |
-DFLATCC_TEST=OFF -DFLATCC_REFLECTION=OFF | |
# See above comment about POSITION_INDEPENDENT_CODE. | |
-DCMAKE_POSITION_INDEPENDENT_CODE=ON | |
-B${CMAKE_BINARY_DIR}/_host_build |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you, is the cmake-format
used for linter? We'll keep in mind for other changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you run cmake-format, then the linters will be happy. Unfortunately, right now we have different linters in github (lintrunner) and inside of Meta, so they don't always agree, and there's no way for you to see the Meta-internal linters. We plan to disable the internal linters so that lintrunner in github is the source of truth.
Thanks for making this final fix! I'll try landing again today.
@dbort has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
Some of the CI jobs are timing out after 90 minutes; usually they take <10 minutes. I doubt it's because of this PR, but I want to make sure they pass before landing this. Looking into it. |
@haowhsu-quic could you please rebase this on top of a recent |
e5c1847
to
796a634
Compare
@dbort has imported this pull request. If you are a Meta employee, you can view this diff on Phabricator. |
We're still trying to figure out why these jobs are failing; something is weird here. |
I cloned this PR into #4515 to see if the jobs still fail there. |
The cloned PR passed all tests, so I'm comfortable force-landing this PR. I'm trying again now. |
This broke the test-coreml-delegate build:
I will revert this for now. |
This reverts commit 15815dd, which broke the test-coreml-delegate job. Details in pytorch#4312 (comment)
Summary: This reverts commit 15815dd, which broke the test-coreml-delegate job. Details in #4312 (comment) Pull Request resolved: #4528 Reviewed By: cccclai Differential Revision: D60696305 Pulled By: dbort fbshipit-source-id: 12677330b31b9fa180b79ec9daa5eef05cfd48d7
As mentioned in #4297, the original flow makes host / cross build happen concurrently. This change moves host build process into cmake configuring stage and refine related dependencies.
Test Plan:
backends/qualcomm/script/build.sh --release
, we could check if the compiling process successfully finished.