Re: Patching jit_movi

[Marc Nieper-Wißkirchen]

Am Do., 1. Dez. 2022 um 18:55 Uhr schrieb Paulo César Pereira de
Andrade <paulo.cesar.pereira.de.andrade@gmail.com>:
>
> Em qui., 1 de dez. de 2022 às 11:45, Marc Nieper-Wißkirchen
> <marc.nieper+gnu@gmail.com> escreveu:
>
>   Hi Marc,
>
> > Currently,  the constant in jit_movi is ignored when we patch it with a 
> > label.
>
>   Branches do not even receive an argument, as it must be patched.
> This is because branches not patched are so uncommon it is not a
> reason to force all others to have an ignored argument.
>
>   For jit_movi it is a special pattern. Internally there is a mix of movi and
> movi_p, where the '_p' suffix means the value is not used..
>
> > Could we change this so that the constant is retained as an additive offset?
> >
> > My code currently looks like
> >
> > jit_patch_at (jit_movi (JIT_R0, 0), node);
> > jit_addi (JIT_R0, JIT_R0, tag);
>
>   Not certain if I understand the usage. But probably it can be done
> with some other construct.

The usage is for a VM with tagged pointers (to support GC).  At the
end of this code snippet, R0 should contain the tagged address of the
label NODE.  The value R0 will then be passed around.  Other code can
then detect how R0 is tagged.  If then a jump is supposed to happen at
the original target NODE, the tag is substracted first.

>
>   Please provide a more complete example usage.

I hope the above explanation helps.

>
>   Is it creating a jump target?
>
> > It would be preferable if I could write:
> >
> > jit_patch_at  (jit_movi (JIT_R0, tag));
>
>   If the current point in jit generation is the equivalent of tag as
> a label, you can write:
>
> jit_patch(jit_movi(JIT_R0, 0));
>
> what will cause it to move to JIT_R0 the instruction pointer just after
> the movi. For example, mimic'ing with check/lightning:
>
> .disasm
> .code
>     movi %r0 implicit_label
> implicit_label:
>     addi %r0 %r0 1
>
> and with --enable-devel-disassembler output:
>
>     movi %rax 0x1fc5650
>     0x7f412f201000    movabs $0x7f412f201010,%rax
> L0: %rax
>     0x7f412f20100a    nopw   0x0(%rax,%rax,1)
>     #note x.tst:4
>     addi %rax %rax 0x1
> # :x.tst:4
>     0x7f412f201010    add    $0x1,%rax

This code is suboptimal; what I am looking for is something like

movabs $x7f412....010 + TAG, %rax
...
L:
7f412...010 ...

For example, linker relocation types (like R_X86_64_64 for the AMD64
ABI) allow a fixed addend as well.

Thanks,

Marc