[Top][All Lists]

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

Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc

From: Paulo César Pereira de Andrade
Subject: Re: [Lightning] Re: Update on testcase [was: sse instructions and gcc warnings]
Date: Tue, 10 Aug 2010 23:43:12 -0300
User-agent: SquirrelMail/1.4.19

Paulo César Pereira de Andrade wrote:

  Sorry to replying to myself.

>   Hi again,
>   Now I think I got a good solution for ld*f/st*d and ld*d/st*f. It
> requires implementing jit_extr_f_d and jit_extr_d_f. Doing it implicitly
> would be a bad idea IMO as one may actually work only with single
> precision floats, and having lightning implicitly upgrading them
> would be bad...
>   I also changed a bit fp-common.h to define the jit_extr_f_d and
> jit_extr_d_f fallback for i386 (using i387) where values are
> already double precision.

  This is not required. I thought it would be, for i386, because the
test case would not compile in x86_64 if they were not defined, what
was a temporary condition.

>   Well, I needed some net browsing, but got most of the information
> from Wikipedia.
>   The good thing was that all bits were already inplace, was only
> needing to define the proper macros. Also, note that jit_extr_d_f
> requires SSE2 or newer, but jit_extr_f_d is plain SSE.

  Also wrong, jit_extr_f_d needs SSE2. I was with other opcode in
my head, that I implemented but reverted, because it both, did not
do what I wanted and was not required. Was thinking of one of the
unpack opcodes, based on objdump -d -S output from a small C test
program, and checking what gcc generated...

>   Now the remaining x86_64 problem is sign extending 64 bit values,
> (I will try to figure out how to correct it later, should be easier
> than the floats solution) so, if #define'ing sign_extend to 0, it
> will pass all tests.
> Thanks,
> Paulo


reply via email to

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