Wasmtime GitHub notifications bot (Jul 23 2020 at 15:00): Wasmtime GitHub notifications bot (Jul 23 2020 at 15:00):github-actions[bot] commented on Issue #2068:
Subscribe to Label Action
cc @bnjbvr
<details>
This issue or pull request has been labeled: "cranelift", "cranelift:area:aarch64", "cranelift:area:machinst", "cranelift:area:x64", "cranelift:meta"Thus the following users have been cc'd because of the following labels:
- bnjbvr: cranelift
To subscribe or unsubscribe from this label, edit the <code>.github/subscribe-to-label.json</code> configuration file.
Learn more.
</details>
Wasmtime GitHub notifications bot (Jul 24 2020 at 12:46):julian-seward1 commented on Issue #2068:
One more general comment, in response to Chris' general comment:
It also strikes me (as a driveby thought) that we really should try to unify the sequence-of-instruction-lowerings between lowering time and emission time; the way in which we do a late expansion at emission time when there is local control flow involved is kind of bothersome.
I actually like the ability to hide a bunch of real insns inside a single
X64::Inst. I think it gives us a lot of flexibility without adding global complexity. I've use this facility quite extensively in the aarch64 atomics work, too. My only concern (and it is a big one) is that of correctness with respect to register allocation, when there are tmp regs used inside the sequence, or earlyclobber inputs. As I commented several times above, I think we should step back, get our story about them straightened out, and audit.I suspect that at least some part of the reason that Ion compiles so much faster than us is that it processes fewer, larger "units", and I wonder if that's a trick we can adopt, without sacrificing generated code quality. For example, a single
Insnthat does an compare and (one-way? two-way?) conditional branch; similar for conditional moves; trap if reg nonzero, or trap if (reg & imm) nonzero.
Last updated: Oct 23 2024 at 20:03 UTC