[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