My compiler has a WASM backend in addition to a QBE backend, so I feel somewhat
qualified to speak on this :)
> May I ask you to elaborate a bit more on this?
WebAssembly requires structured control-flow. That is, the sort of high level
logic you would write in a C program, sans goto. (Ifs, loops, break, continue)
QBE IR is a control flow graph, which is a graph of basic blocks connected by
jumps. Since arbitrary jumps aren't valid WASM, structured control flow must be
recovered from the CFG.
> Do you see WASM intrinsically incompatible as a target with the premises
and/or the current architecture of QBE?
The good news is that structured control flow can always be recovered from a
control flow graph, so it is not a show-stopper, just a pain.
(caveat: If the CFG is irreducible, it must first be made reducible.)
> Or, would you have any references to read and better understand what you mean
by that?
Here is a long github issue thread with WASM users complaining about the
current design, and the authors providing some justification for it:
https://github.com/WebAssembly/design/issues/796
I recommend this paper for an algorithm to emit structured control flow from a
CFG:
https://dl.acm.org/doi/abs/10.1145/3547621
I implemented the algorithm this paper describes for my compiler.
If anyone wanted to take up the task of adding a WASM backend to QBE,
I would be happy to consult based on my experience.
Finally, here is a link to the implementation in my compiler:
https://github.com/DenialAdams/roland/blob/master/rolandc/src/backend/wasm.rs
Just leaving it for posterity, not sure how helpful it would be.
I believe qbe does not make aggressive transformations
on the cfg. So if you design your frontend in such a
way that it outputs wasm-friendly cfgs then you may
be able to write a simple pass in qbe to recover wasm
out of the optimized ir, probably some place before
instruction selection.