Re: [Lightning] Feature Request: Allow patching of st(x)i and ld(x)i

[Paulo César Pereira de Andrade]

Em ter, 3 de set de 2019 às 14:11, Marc Nieper-Wißkirchen
<address@hidden> escreveu:

  Hi Marc,

> >   Note that it will still internally become a movi(..), ldr(...) pair on
> >  a very large amount of inputs.
> >   For x86_64 it will be a direct load from memory only if the address can
> > be 32 bit signed extended to a 64 bit address.
> >   For several other ports the value will be far smaller, for example, could
> > need to be the first 16k bytes or similar value.
> >   Usually the best approach would be to have a base register, and then use
> > ldxi with a constant offset. But that could mean keeping a register
> > exclusively for the base pointer of global the data.
>
> Apart from the fact that I am short on the register side, I currently
> have no control where the malloc'd area lies in memory, so it is
> unclear where a base pointer should point at.

  There should be some way to  store the malloc result at
some address known before jit_emit, then load it with jit_ldi.
Depending on code, could call a C function to resolve, or,
could even call malloc from jit :) and use a "local" variable
to store it, using jit_allocai and ldxi/stxi using the special
JIT_FP register.

> It would be a nice addition to GNU lightning if user data could be
> stored along the code, for which GNU lightning could use IP-relative
> addressing if available on the target architecture.

  Lightning does not export any interface for something like this.
There is jit_code_data, but it is used only internally, to create a
memory buffer for constants, when it is significantly cheaper to
load from memory.

  Mixing data with code is not a good idea. Need jumps over it,
and can easily cause it to create expensive branches due to
needing to jump over data when creating normal jumps, and
the worst would be adding noise to the processor cache. Still,
lightning implements it for armv5 when not in thumb mode.

> If we had this, I wouldn't have to resort to jit_patch_abs. (By the
> way, jit_patch_abs is not yet documented in the manual, I think.)

  Good catch. It should be documented.

> --
>
> Marc

Thanks,
Paulo