qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH] tcg: Fix helper function vs host abi for float1


From: Laurent Desnogues
Subject: Re: [Qemu-devel] [PATCH] tcg: Fix helper function vs host abi for float16
Date: Thu, 24 May 2018 15:06:42 +0200

On Thu, May 24, 2018 at 2:28 PM, Peter Maydell <address@hidden> wrote:
> On 23 May 2018 at 06:10, Laurent Desnogues <address@hidden> wrote:
>> Some AArch64 tests I had that previously failed on a x86-64 host now pass.
>>
>> Tested-by: Laurent Desnogues <address@hidden>
>
> Thanks for the testing.
>
>> Perhaps the two occurrences of the following comment in
>> target/arm/translate-a64.c could be removed along with this patch:
>>
>>             /* write_fp_sreg is OK here because top half of tcg_rd is zero */
>
> I think this comment remains correct, doesn't it? At this point
> we've just called a helper routine which is 'f16' return. With
> this patch, that means that (by virtue of being uint16_t return
> type as far as C is concerned), it will have returned a 32 bit
> value into the TCGv_i32 whose bits [31:16] are zero, as the
> comment says. We require that because we're using
> write_fp_sreg() to update the vector register, and that function
> zeroes out bits [127:32] and assumes [31:16] from its input
> should all go into the vector register; but the instruction's
> semantics require [127:16] to be zeroed, and it's only because
> we know [31:16] are zero in the return value that we can
> get away with calling write_fp_sreg() rather than requiring a
> new write_fp_hreg().

I was reading the comment as somehow explaining the assumption of the
ABI clearing the top 16-bit of 16-bit return value.  But I agree it
still makes sense as it is.

Thanks,

Laurent



reply via email to

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