On 11/21/18 2:15 AM, Alistair Francis wrote:
>> Will the riscv-32 compiler use a FSTD insn to implement atomic_set for 64-bit?
>> If not, you may be just better off using the indirect method.
>
> I'm not sure. Is the indirect method just using atomic set, because
> that is what I have now?
It's controlled by TCG_TARGET_HAS_direct_jump, and goes through here:
> + case INDEX_op_goto_tb:
> + if (s->tb_jmp_insn_offset) {
> + /* direct jump method */
> + s->tb_jmp_insn_offset[a0] = tcg_current_code_size(s);
> + /* should align on 64-bit boundary for atomic patching */
> + tcg_out_opc_upper(s, OPC_AUIPC, TCG_REG_TMP0, 0);
> + tcg_out_opc_imm(s, OPC_JALR, TCG_REG_ZERO, TCG_REG_TMP0, 0);
> + } else {
> + /* indirect jump method */
> + tcg_out_ld(s, TCG_TYPE_PTR, TCG_REG_TMP0, TCG_REG_ZERO,
> + (uintptr_t)(s->tb_jmp_target_addr + a0));
> + tcg_out_opc_imm(s, OPC_JALR, TCG_REG_ZERO, TCG_REG_TMP0, 0);
> + }
> + s->tb_jmp_reset_offset[a0] = tcg_current_code_size(s);
> + break;
where as you've correctly implemented, the indirect jump loads a destination
from memory (atomically, via a single load insn), and then branches to it.
The direct jump method avoids the load from memory, but then one has to be able
to modify the insn(s) that perform the jump with a single atomic_set. Which in
this case, means that the two insns must be aligned so that we can perform a
single aligned 64-bit store.
I recommend at least starting with the indirect method because it's easier.
r~