lightning
[Top][All Lists]
Advanced

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

[Lightning] On the benefits of inlining


From: Ludovic Courtès
Subject: [Lightning] On the benefits of inlining
Date: Fri, 02 Sep 2005 18:57:07 +0200
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

Hi,

Lightning doesn't make it very easy to generate inlinable code.  Using
GCC's ``labels as pointers'' extension, I managed to generate a simple
multiplication function whose code looks like this:

  jit_leaf (0);

  /* Save the registers we'll use.  */
  jit_pushr_p (JIT_R1);
  jit_pushr_p (JIT_R2);
  operand_movi = jit_movi_p (JIT_R1, NULL);

  /* Dereference the pointer to the input operand.  */
  jit_ldr_p (JIT_R2, JIT_R1);

  jit_muli_ul (JIT_R2, JIT_R2, some_value);

  /* Store the result back at the address pointed to by R1.  */
  jit_str_p (JIT_R1, JIT_R2);

  /* Restore the registers and jump out.  */
  jit_popr_p (JIT_R2);
  jit_popr_p (JIT_R1);

  final_jump = jit_jmpi (NULL);

Then both OPERAND_MOVI and FINAL_JUMP appropriately are patched before
jumping (not calling) to the generated code.

While it works, it turns out to be quite inefficient.  It's even
slightly less efficient than the function-call-style equivalent.

Have you ever tried such things?  Clearly, this would only make sense
for very small pieces of code like this one (there's actually only one
useful instruction so making it a function induces too much overhead).

I believe it would be useful to have back-ends export a mapping between
the Lightning register names and the corresponding GCC register names
for that architecture.  In the above example, it would allow to pass the
input operand directly into the appropriate register (via an `asm'
statement) and fetch the result likewise.

What do you think?

Thanks,
Ludovic.




reply via email to

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