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

[Paulo César Pereira de Andrade]

Em qua, 4 de set de 2019 às 06:25, Marc Nieper-Wißkirchen
<address@hidden> escreveu:
>
> Hi Paulo,

  Hi Marc,

> >   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.
>
> Thanks for looking into it.
>
> I think mixing code and data in the way you describe (and which, I
> also think, is not a good idea) is not necessary.
>
> What I am thinking of is a pseudo instruction (returning both a label)
> of the form
>
> data p, n, a
>
> Here, P is a (char const *) pointing to some data or NULL, N the size
> of the data in bytes, and A a suitable alignment.

  The current private jit_data(void*, length, align) could be somehow
adapted to export this interface. It returns a shared jit_node_t*, and
before jit_emit it patches instructions, to avoid duplicates. It is
used mostly for float/double constants. It internally patches the
instructions. It does not return a 'label' (jit_code_label) but a 'data'
(jit_code_data) that uses an offset to a data buffer somewhere. Such
interface should be very carefully thought out, or things might become
too complicate.

> When emiiting the jitted code, GNU lightning would then reserve
> somewhere (!) sufficient space of N bytes and would fill it (i.e.
> memcpy) using the data pointed to by P if any. On jit_destroy (), the
> data section is freed as well. As jit_data is supposed to return a
> label, it can be used with jit_patch_at so that the code can access
> the data.
>
> Note that the data does not have to be (and shouldn't be) embedded in
> the middle of the code. It can be stored at the end of the generated
> code.

  I believe it would be better to use jit_get_data() and jit_set_data(),
and possibly jit_get_code() and jit_set_code(), that already have a
somewhat complicated interface, but allow very small memory usage
by disabling any kind of data buffer, or letting the user set the data
buffer, but really, the most useful feature is as described in the info
page:
       ...
       jit_realize();                        /* ready to generate code */
       jit_get_data(NULL, NULL);
       jit_set_data(NULL, 0, JIT_DISABLE_DATA | JIT_DISABLE_NOTE);
       ...
to completely disable an extra data buffer.

> The idea is that GNU lightning can control where the data lies in
> relation to the generated code (or knows it a least), so it can use
> (on some targets) more efficient IP-relative addressing of the data.

  It can already do it, I mean IP-relative addressing. Because when
emiting code, it knows the instruction pointer and the data address.
Just that it is a missed optimization on the ports that support it.
It normally just implements the worst case.
  Well, there are plenty of backend specific optimizations that can
be done as well. But overall, this would require a lot of time for
not too much gain, and make things significantly more complex. Still,
would be something good to have.

> Best,
>
> Marc

Thanks,
Paulo