[Top][All Lists]

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

Re: [Lightning] SPARC Fixes

From: Paolo Bonzini
Subject: Re: [Lightning] SPARC Fixes
Date: Tue, 31 Oct 2006 09:25:17 +0100
User-agent: Thunderbird (Macintosh/20060909)

Ludovic Courtès wrote:

My Arch branch[*] cotains a few fixes for SPARC, namely:

  * Fixed a typo in `jit_modi' which prevented compilation of programs
    making use of it (patch-11).

  * Fixed `jit_immsize' which passed its arguments to `_siP' in the
    wrong order (patch-12).  This macro is used by `jit_prepare_y' and
    `jit_clr_y' in order to make sure register Y is not read from at
    least 3 instructions after.  This bug had no negative impact beside
    the output of a warning ("left shift count >= width of type").  I
    added a `divi' test case (patches 14 and 15) which thusly cannot
    catch this bug (but anyway, too many tests is better than not
    enought ;-)).
Applied, thanks.
  * Fixed the use of `JIT_RET' (patch-19).  Lightning's `JIT_RET'
    actually maps to two registers on SPARC: %i0 is where a procedure's
    own return value should be put, and %o0 is where the return value of
    a called procedure should be read.  The way I fixed this is simple,
    although not very efficient, but I couldn't think of anything
    better: any `calli' or `callr' is followed by a `mov %o0, %i0' so
    that one can expect %i0 to always contain the callee's return value.
This is wrong, you have to use jit_retval_i to retrieve %o0 exactly for this reason. It is also wrong because, IIRC, %i0 is a callee-save register and you cannot write into it if a function returns void. Would you mind preparing a patch-20 to undo the JIT_RET changes?
    This patch increases the size of the stack frame as it is created
    during a function prolog so that there are always
    `JIT_MAX_STACK_AUTOMATIC_AREA' words available to put registers to
    (at the top of the stack frame, as required by the SysV ABI SPARC
    Supplement and as suggested in Appendix D of the SPARC V8 specs).
    This effectively limits the number of registers that can be pushed
    from within a function, but I think that shouldn't be a problem.
Another possibility (simpler for now to implement) is that if JIT_MAX_STACK_AUTOMATIC_AREA is defined, clients should be careful not to push more than that amount of words. Or we could just deprecate pushr/popr and define a better way to provide stack space for spills.
    Under `_ASM_SAFETY', `pushr' "overflows" and `popr' "underflows" are
    detected.  I think we should document `_ASM_SAFETY' and perhaps
    define it by default.
That's --enable-assertions.  :-)
    Instead of having a hard limit on the number of registers that may
    be pushed, we could also patch the `save' instruction based on the
    actual number of `pushr' encountered in the function's code, but I'm
    not sure it's worth it.
That would be the way to provide stack space for spills -- a lightning instruction patching the `save' on the SPARC, and on other architectures compiling to subr JIT_SP, JIT_SP, N.


reply via email to

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