[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lightning] Omit frame pointer

From: Marc Nieper-Wißkirchen
Subject: Re: [Lightning] Omit frame pointer
Date: Mon, 04 Sep 2017 20:22:22 +0000

Paulo César Pereira de Andrade <address@hidden> schrieb am Mo., 4. Sep. 2017 um 21:57 Uhr:
2017-09-03 11:32 GMT-04:00 Marc Nieper-Wißkirchen <address@hidden>:
> Some architectures like the x86 (32 bits or 64 bits with System V ABI) have
> only very few registers available. For those architectures it makes a lot of
> sense to make the frame pointer available as another callee-saved register.

  Lightning already makes available the JIT_FP register. So, one can use
it as a general purpose register, as long as it is restored before epilog and
properly used with jit_alloca*.

Does it currently work to modify JIT_FP in the body of a function when GNU lightning has to spill registers into the stack frame? Would getarg and putarg work?

> (This mimicks the GCC option -fomit-frame-pointer.)
> For this to work, the stack pointer is used to access the locations in the
> current frame. The value returned by the allocai instruction will be
> adjusted because it will be relative to the stack pointer, not the frame
> pointer.
> Would this introduce any limitations to the code produced?

  This would require a far more complex function body analysis, as the
point of omit-frame-pointer would be to make a shorter prolog/epilog.

That's one point. Freeing a register is another one; the more important one, I guess.
If jit_allocar were used (run time alloca) it would still need to save the

It could be up to the user code: Either the user code wants the possibility of using allocar, then JIT_FP has to play its current role; or the user promises not to use allocar; then JIT_FP could be freed.

(This could be done in the GNU lightning ABI by marking functions that forgo allocar, much as tramp and frame mark functions.)
frame pointer. For lightning, larger function bodies are better, as it indeed
does not do a very good job optimizing prolog/epilog.
  It probably would require an API change to have jit_allocai receiving
a "node" argument, to be patched later with the proper offset, like
labels for branches.

What about providing special load and store instruction to the stack area allocated by jit_allocai? At the moment jit_allocai returns a number to be used as an offset to JIT_FP. The special load and store operations could take this number and either use it as an offset relative to JIT_FP (normal functions), or as an offset to be adjusted relative to the stack pointer (functions omitting the frame pointer).

> Marc


reply via email to

[Prev in Thread] Current Thread [Next in Thread]