You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The elephant in the room, so to speak, is that qemu-user can't fork(). This means any tests that try to fork will fail, but that's worked around by limiting the tests that are used for the guiding or ignoring failures.
Feature or enhancement
Proposal:
The current makefile rules for profiled guided optimisation don't support cross at all:
cpython/Makefile.pre.in
Lines 691 to 692 in fb4cb7c
This is understandable, as the point is to run the target code and on the host this isn't generally possible.
However,
qemu-user
does let us run target code on the build host with only a little fuss and various build tools allow the use of this to run target binaries in limited cases, such as when probing capabilities or running tests. For example, Meson's cross files support anexe_wrapper
script (https://mesonbuild.com/Cross-compilation.html) and CMake has aCMAKE_CROSSCOMPILING_EMULATOR
variable (https://cmake.org/cmake/help/latest/variable/CMAKE_CROSSCOMPILING_EMULATOR.html).I propose adding something similar for the PGO execution. Strawman proposal:
--with-cross-runner
toconfigure
to let the user specify a wrapper script that can be used to run target binaries on the build host.python3
when generating the PGO training data with this scriptPrior art to demonstrate that this is at least feasible can be found in the Yocto Project at https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/python/python3/0001-Makefile.pre-use-qemu-wrapper-when-gathering-profile.patch. We generate the
pgo-wrapper
script (which simply callsqemu-user
with arguments) during the build.Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
No response
The text was updated successfully, but these errors were encountered: