Rescheduling native compiler passes.

[agatti]

As per subject, is it possible to reschedule compiler passes from a native code generator backend? Or if not, can that be worked around without patching too much code?

On RISC-V most of the code sequence generators to implement for a native code backend can have different sequences of varying length depending on the input values and that doesn't seem to play nicely with how the compiler expects things to be.

From what I understand, the compiler only passes the correct values to generate code for on the last pass, and by then the code should not change in length (as per what's in docs/develop/compiler.rst and the assertion at py/asmbase.c on line 93). The problem is that I generate wrong code sequences until it's too late for the compiler to handle.

I worked around that by padding code blocks with NOPs, but for the average function the result is having a generated native block that's more than 30% made up of NOPs.

I can probably patch the ASM API by changing the return code for ASM_END_PASS into a boolean indicating whether the pass must be re-run or not and act accordingly, but in that case would the compiler throw away what it computed thus far making this pointless?

Thanks!

[dpgeorge]

The Thumb2 emitter has a lot of instructions that are varying length; see eg asm_thumb_mov_reg_i32_optimised(). And they work fine without additional passes. So I'm wondering how RV32 is different here?

Note that the bytecode emitter does have cases where the bytecode can change size in the last pass, and in that case is does request another pass from the compiler, until the bytecode size stops changing. But there, the bytecode can only decrease in size in the final pass(es), which makes it simpler.