f31fb0044d
The problem with callr is that the register that contains the function to be called, can be overwritten by the logic that moves the values into argument registers. To fix this, I added a get_callr_temp function that should return a platform specific register that is not used to pass arguments. For Aarch64/Arm the link registers seems to work; for Amd64/i686 the RAX register. The function/tmp pair becomes an additional argument to the parallel assigment; this way the original function register is not accidentally overwritten. The problem with calli is that it may not have enough temp registers to move arguments. The windmill paper says that at most one temporary register is needed for the parallel assignment. However, we also need a temp register for mem-to-mem moves. So it seems that we need a second temporary. For Amd64/i686 we have only one temporary GPR and one temporary FPR. To fix this, I modified the algorithm from the paper a bit: we perform the mem-to-mem moves before the other moves. Later when we need the temp to break cycles, there shouldn't be any mem-to-mem moves left. So we should never need two temps at the same time. * lightening/lightening.c: (get_callr_temp): New function; need for each platform. (prepare_call_args): Include the function/callr_temp pair in the arguments for the parallel assignment. * lightening/x86.c, lightening/arm.c, lightening/aarch64.c (get_callr_temp): Implementation for each platform. * lightening/arm.c (next_abi_arg): Fix the stack size for doubles. * tests/call_10_2.c, tests/callr_10.c: New tests. * tests/regarrays.inc: New file. Common code between the above two tests that would be tedious to duplicate. |
||
|---|---|---|
| lightening | ||
| tests | ||
| .gitignore | ||
| .gitlab-ci.yml | ||
| AUTHORS | ||
| ChangeLog | ||
| ChangeLog.lightning | ||
| COPYING | ||
| COPYING.DOC | ||
| COPYING.LESSER | ||
| lightening.am | ||
| lightening.h | ||
| lightning.texi | ||
| NEWS | ||
| README.md | ||
| THANKS | ||
Lightening
Lightening is a just-in-time code generation library derived from GNU Lightning, adapted to the purposes of the GNU Guile project.
Use
gcc -flto -O2 -g -o lightening.o -c lightening/lightening.c
gcc -flto -O2 -g -o my-program lightening.o my-program.c
See the GNU Lightning manual for more on how to program against Lightening (much of the details are the same).
What's the difference with GNU Lightning?
This project is called Lightening because it's lighter-weight than GNU Lightning. When you go to generate code at run-time with GNU Lightning, what happens is that you build up a graph of nodes which GNU Lightning "optimizes" before finally emitting machine code. These optimizations can improve register allocation around call sites. However they are not helpful from a Guile perspective, as they get in the way of register allocation that we need to do; and they actually prevent access to all the registers that we would like to have.
Guile needs a simple, light-weight code generation library. The GNU Lightning architecture-specific backends provide the bulk of this functionality, and Lightening wraps it all in a lightweight API.
Supported targets
Lightening can generate code for the x86-64, i686, ARMv7, and AArch64 architectures. It supports the calling conventions of MS Windows, GNU/Linux, and Mac OS.
On i686, Lightening requires SSE support. On ARMv7, we require hardware floating-point support (the VFP instructions), as well as the UDIV/SDIV instructions.
Lightening is automatically tested using GitLab's continuous integration for under the supported architectures, for GNU/Linux; for a list of recent jobs, see the CI page.
Future targets
Lightening has some inherited code from GNU Lightning for MIPS, PPC64, and s390. Patches to adapt this code to the Lightening code structure are quite welcome.
RISC-V support would be fun too.
Status
Lightening is used in GNU Guile since version 2.9.2 and seems to work well.