Re: [Lightning] sse instructions and gcc warnings

[Paulo César Pereira de Andrade]

Paolo Bonzini wrote:

  Hi,

> On 07/26/2010 10:35 PM, Paulo César Pereira de Andrade wrote:
>>>>     This started happening when I added calls to jit_str_c,
>>>> jit_str_uc,
>>>> etc, and apparently doesn't happen if there are only calls to
>>>> jit_stxi_s, jit_stxi_us, etc, but I am not 100% sure now.
>>>
>>> Yes, jit_str_c and jit_str_uc are indeed responsible.

  I tried to build a simple test case to prevent/detect other problems
as I may again delay a bit more work in the jit backend, to work on
other optimizations/features in the language (I don't want to specialize
it too much for now as there several things that may still change).

  But I could not get a simple test to compile due to jit_replace...
it appears to only affect JIT_Vx, and in my current code it works
because I used JIT_Rx, I believe...

  Anyway, I built a temporary rpm with the latest git snapshot, but
will not submit it to the Mandriva build system because now it fails
with:

-%<-
$ gcc lightning-test.c
lightning-test.c:68:45: error: macro "jit_replace" requires 4 arguments,
but only 3 given
lightning-test.c: In function ‘test’:
lightning-test.c:68: error: ‘jit_replace’ undeclared (first use in this
function)
lightning-test.c:68: error: (Each undeclared identifier is reported only once
lightning-test.c:68: error: for each function it appears in.)
lightning-test.c:69:46: error: macro "jit_replace" requires 4 arguments,
but only 3 given
lightning-test.c:89:45: error: macro "jit_replace" requires 4 arguments,
but only 3 given
lightning-test.c:91:46: error: macro "jit_replace" requires 4 arguments,
but only 3 given
-%<-

  The x86_64 output, with CHECK_FLOAT defined to 1 is:
-%<-
$ gcc -O0 -g3 lightning-test.c
$ ./a.out
check0:58: 0.000000
check1:37: 0x40571f 0x4007d7
check1:38: 0x40572c 0x1
check1:39: 0x405737 0x1
check1:40: 0x405744 0x1
check1:43: 0x405767 0x1
check1:45: 0.000000 0.000000
-%<-
and with CHECK_FLOAT defined to 0 is no output (expected behavior),
so it appears to be corrupting the stack/data.

  Strange that I did not get char/short errors in my backend also.
Probably because I store to a long (the vm register), and then to
the given type, so I was only hit by it not sign extending (or
always zero extending?). This test was also mean't to ensure the
problem was not the fact that the 32 top bits could have been
already zero...

>>    Load/store of float32 simply does not work, examples:
>>      jit_ldr_f(JIT_FPR0, JIT_R1);
>>      jit_stxi_d(..., JIT_V1, JIT_FPR0);
>> and
>>      jit_ldxi_d(JIT_FPR0, JIT_V1, ....);
>>      [...]
>>      jit_str_f(JIT_R1, JIT_FPR0);
>>
>>    Another problem is that:
>>      jit_ldr_c or jit_ldr_s   (JIT_R0, JIT_R1)
>>      [...]
>>      jit_stxi_l(JIT_R0, JIT_V1, ...);
>> does not sign extend the top 32 bits, but jit_stxi_ul paired with
>> jit_ldr_uc or jit_ldr_us sign extends (zeros out top 32 bits). From
>> the test cases I currently use, it appears to sign extend int32, but
>> I just added all small ints to the same fallback for now...

  Floats have something else strange, as movi_f also coredumps (sigills?)
in x86_64. Since in my language it calls mpfr_set_d and prints a mpfr_t,
the float usually is like 1e-32.

  The attached test needs some extra tests to also check for load/store
with "implicit" conversion, i.e. jit_ldxi_c/jit_stxi_i, and in all
combinations, i.e. jit_ldr_x|jit_ldxi_x / jit_str_x|jit_stxi_x only
skipping integer/float registers of course :-)

  I can write a simple file for extra tests, but I am sorry currently
my assembly skills and knowledge of lightning internals are very weak,
so for now I can only cheer :-)

Thanks,
Paulo

lightning-test.c
Description: Text Data