[Top][All Lists]

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

[Lightning] Re: jit_allocai

From: Ludovic Courtès
Subject: [Lightning] Re: jit_allocai
Date: Sun, 5 Nov 2006 20:44:36 +0100
User-agent: Mutt/1.5.4i [Guile enabled]


2 days, 2 hours, 55 minutes, 45 seconds ago, Paolo Bonzini wrote:
> Are you willing to give a stab at implementing jit_allocai?  The 
> interface should be that jit_allocai(N) returns a value RET usable as an 
> offset in jit_ldxi(reg, JIT_FP, OFS), where RET <= OFS < RET + N.

I implemented it and tested it on SPARC:

      Implemented `jit_allocai' for SPARC.
      tests/allocai.c: New test case.

Note that I kept `pushr' here (with the register number limitation),
which your may or may not want to keep for 1.3 (there are arguments in
both directions, but I think that `pushr' could be marked as deprecated
in 1.3 and only actually removed in the next release).  Thus, patch-28
relies on bits from patch-19 that you dismissed earlier.

Due to lack of time, I did not try to modify `rpn.c' to use
`jit_allocai' instead of `pushr', hence the new test case which is much
simpler and targetted.  I did not augment the documentation either but I
can do it if you want.

And of course, I did not implement the thing on the other arches.  ;-)


PS0: Patch-30 fixes `_d22 ()' on SPARC (see patch log for details).

PS2: Patches 23 and 27 remove generated files (`', etc.) from
     the inventory, which greatly eases merging.

PS3: When cherrypicking patches, could you avoid inserting additional
     changes in the same changeset?  E.g., your patch-6 replays a patch of
     mine _and_ does additional things, which makes merging back into my
     branch harder and makes those changesets "unclean" [0].


reply via email to

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