Re: IR / Argument registers

[Paulo César Pereira de Andrade]

Em seg., 6 de nov. de 2023 às 11:08, Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com> escreveu:
>
> 1.
>
> Paulo, some years you mentioned that you planned to design an IR 
> (target-specific) that can be dumped into a file and can be reloaded later.  
> Has there been any progress in this area, or have the next steps been 
> identified?
>
> Obviously, we would have to be able to mark some immediate as relocatable, 
> and the process replaying the IR would have to provide the relocated values.

  I did not work on it as my initial goal was to have some generic,
not target specific variant.
  This also makes it easy to not provide any kind of source code, so
it was not immediately
important. The need for it is obviously for faster loading.
  As is now, the easiest approach is to create external code to record
offsets and what is
being patched, dump the jit buffer to a file, then reload and patch
again non relative offsets.
  Conditional branches are relative in all ports, non conditional
branches only in special
cases are not pc relative. Patched addresses are encoded as non
optimized instructions
so that any value can be patched.
  Dumping the nodes with all metadata is doable, but there is no
notation for patches of
"extern" functions, that would be easier to resolve with dlsym,  but
likely full of special
cases and far more complex. Better to have custom code that would do
some translation
when loading a dump of the jit code.

> 2.
>
> Paul, also some years ago, sent a patch making JIT_A(n), corresponding to the 
> n-th register argument, available to the user.  Could we eventually get 
> something like it into the upstream version?

  Replying partially for Paul :)

  Paul is using it, but not in any public api. It is not officially
supported to use the argument
registers, but it is perfectly valid and is expected to work. Just be
prepared for things like
an assertion if running out of registers and needing a temporary that
cannot be spilled,
like when needing a temporary to compute a branch target.

  It is "guaranteed" to work on the expected usage, because of the
stress test in check/carg.c.
Depending on what you need, it (check/carg.c) is a very good example
on how to manage
arguments that might be in registers. This is required because
arguments in registers might
be clobbered as the current code does not save/reload it if a function
call is required or there
is a jump to an unknown target (jmpr or jmpi used not as an
unconditional branch).

> Thanks,
>
> Marc

Thanks,
Paulo