what if there are i64 in SELECTcc ?

There should be no i64 in SELECTcc in this case, if the opcodes are i64.cmpcc + if/br_if, the translated IRs should be CMP cmp_reg, i64_r0, i64_r1, SELECTcc i32_cond, cmp_reg, 1, 0. The i64 reg is in CMP IR but not SELECT cc IR.

Got it. Even i64 comparison would return i32 value

I thought the merge action is by default. Why need to disable it ?

For the float/double comparison opcodes, we might translate them into calling native function instead, but not CMP + SELECTcc

In that case, shall we tell that by checking JIT_REG_KIND_XXX?

I just check whether the last two insns are CMP + SELECTcc, as in jit_frontend.c, we will check whether the i32/i64/f32/f64 cmp opcode is followed by br/br_if opcode, and only when yes, we pass merge_cmp_and_if = true to jit_compile_op_block. So in jit_compile_op_block, checking whether the last two insns are CMP + SELECTcc should be enough, the jit reg kind in CMP may be variable, but in SELECTcc, the reg kind of all registers should be i32:

CMP cmp_reg, i32_r0, i32_r1 (or, CMP cmp_reg, i64/f32/f64_r0, i64/f32/f64_r1)
SELECT i32_r2, cmp_reg, 1, 0

I thought get_last_cmp_and_selectcc will do the optimization. So, what does this if(){} do?

get_last_cmp_and_selectcc just returns insn_select and insn_cmp found, here we replace insn_select with Bcc.

got it.

add a else branch to handle error?

The error is handled in jit_codegen_gen_native, after generation machine code for each INSN, seem no need to handle it here?

            if (err_handler.err) {
                jit_set_last_error_v(cc,
                                     "failed to generate native code for JIT "
                                     "opcode 0x%02x, ErrorCode is %u",
                                     insn->opcode, err_handler.err);
                GOTO_FAIL;
            }

What kind of scenario would lead to the error? L5322 and L5332 seem to suggest both situations are acceptable.

a.jmp(imm) may return error. The asmjit might calls re-alloc the memory of its code buffer, I tested cases with valgrind, and found that it sometimes reported that *(int32 *)(stream + 2) = _offset writes the old/obsolete memory before re-alloc, so I refactored the code. Another issue is that if a.jmp fails, we will write offset the invalid place.