adambratschikaye opened PR #10334 from adambratschikaye:abk/move-assembler-x64-generation to bytecodealliance:main:
Generate
assembler-definitions.isleduring build ofcranelift-codegeninstead ofcranelift-assembler-x64. The problem with generating it incranelift-assembler-x64is that that setup requirescranelift-codegento have access to theOUT_DIRused bycranelift-assembler-x64which is prevented when building under Bazel which tries to isolate the builds of separate crates.This change instead adds a function to
cranelift-assembler-x64which returns the expected contents ofassembler-definitions.isleso that the build step ofcranelift-codegencan write it to an accessible directory.<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
adambratschikaye requested wasmtime-compiler-reviewers for a review on PR #10334.
adambratschikaye requested fitzgen for a review on PR #10334.
adambratschikaye updated PR #10334.
bjorn3 submitted PR review.
bjorn3 created PR review comment:
I think it would be nice if this executable kept showing a path to a file on the disk. It is for debugging only and emitting the entire file to stdout would be annoying. Maybe it could write the file to somewhere in the directory from which it is invoked?
adambratschikaye updated PR #10334.
abrown requested abrown for a review on PR #10334.
abrown submitted PR review:
Thank you for submitting this change; I would like to suggest another approach here but I want to make it clear that this looks fine to me as a temporary measure. In thinking about generating the ISLE definitions, I realized recently that they are quite
cranelift-codegen-specific. I think that, if we move the ISLE generation out of thecranelift-assembler-x64-metacrate and directly into thecranelift-codegen-metacrate, we not only fix thisOUT_DIRissue that affects Bazel builds but it's better code organization. All ISLE compilation/generation lives incranelift-codegen-metaalready, so why not move the assembler part of that to the same place? I recognize that may be a larger refactor than this PR and I'm willing to do it since I'm most familiar with all of this. Thoughts?
abrown created PR review comment:
What's unfortunate about this change is that it loses information about the _other_ files generated for the assembler. There were three files and this forgets about two of them.
adambratschikaye updated PR #10334.
adambratschikaye submitted PR review.
adambratschikaye created PR review comment:
What about changing the
mainfunction back to its previous behavior (here)?
adambratschikaye commented on PR #10334:
I think that, if we move the ISLE generation out of the
cranelift-assembler-x64-metacrate and directly into thecranelift-codegen-metacrate, we not only fix thisOUT_DIRissue that affects Bazel builds but it's better code organization.I'm not familiar enough with this part of the codebase to comment on whether it's better organization or not, but I agree it would fix the issue with Bazel builds.
abrown commented on PR #10334:
@adambratschikaye: ok, I pushed #10352 as an alternative to this PR. Can you confirm that it fixes the build issues you were seeing in Bazel?
adambratschikaye closed without merge PR #10334.
adambratschikaye commented on PR #10334:
@adambratschikaye: ok, I pushed #10352 as an alternative to this PR. Can you confirm that it fixes the build issues you were seeing in Bazel?
Yep, that fix works for us. Thanks for helping out!
Last updated: Dec 13 2025 at 19:03 UTC