Re: IR / Argument registers

[Paulo César Pereira de Andrade]

Em seg., 6 de nov. de 2023 às 13:05, Marc Nieper-Wißkirchen
<marc.nieper+gnu@gmail.com> escreveu:
>
> Am Mo., 6. Nov. 2023 um 16:38 Uhr schrieb Paulo César Pereira de Andrade 
> <paulo.cesar.pereira.de.andrade@gmail.com>:
>>
>> 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.
>
>
> Thanks! If the generated code is PC-relative, this looks indeed like the best 
> approach.

  Only conditional branches are pc relative.

> What do you mean by "non-conditional branches only in special cases"?  This 
> would, of course, break relocating the code. Do you think these cases can be 
> identified and avoided?  Or would a flag be possible that makes GNU lightning 
> avoid non-PC-relative instructions?

  Relative non conditional branches when the distance is known to be
in range and
there is some always true condition.

  There are no optimized patches (with small/large relative displacements). They
would be backend specific anyway.
  The easiest approach is to just use jit_movi() on addresses to be able to
record where to patch with jit_address() (jit_address() must be called after
code generation), and use only jit_jmpr and jit_callr. Other branches are
PC relative, no need to make it worse on purpose.

>
>>
>> > 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).
>
>
> That GNU lightning can run out of registers is not directly related to 
> argument registers, is it?  There are some targets that do not have any 
> register arguments, so even if all register arguments couldn't be clobbered 
> on the some target, the situation wouldn't be worse than on a target without 
> any register arguments, would it?
>
> It would be great if it could be documented how many registers are allowed to 
> be live at each point.  Without it, an aggressive register allocator might 
> accidentally go beyond GNU lightning's limits.
>
> As for the JIT_A(n) arguments, if everything works as "guaranteed", maybe 
> they can be made an official part (with the note that each call and unknown 
> jump will clobber them).

  The default number of argument registers is zero. Using JIT_R3 or larger
as well as JIT_V3 or larger needs knowing backend specific information.
  The only case where there are not registers is the arm port when there
is no fpu. In that case registers are faked and emulated in the stack.

  Could indeed define JIT_A_NUM, JIT_FA_NUM, and provide the JIT_A()
and JIT_FA() macros. Using it also might need several calls to jit_live()
and understanding the conditions such a register is considered dead.
Well, it is the same as JIT_Rx, so, nothing special.

  There might be special corner cases to be discovered, as usually the
first argument is also the return value.  While very unlikely, it is possible.

   Before extending too much Lightning, it is required to have very good
error handling and reporting. Just calling abort() is not much helpful, really
bad for a shared library, and having more and more ways to allow code
generation or runtime abort() calls without a clear explanation is not a
good idea. Should also change the assert() calls to some way of having
error handling. Possibly not define NDEBUG if not in a DEBUG build, and
having some error callback that would allow cleaning any resources.

> Thanks,
>
> Marc
>
>>
>> > Thanks,
>> >
>> > Marc
>>
>> Thanks,
>> Paulo