From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45119) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fLpxG-0002rG-Az for qemu-devel@nongnu.org; Thu, 24 May 2018 09:07:01 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fLpx6-0002pR-KG for qemu-devel@nongnu.org; Thu, 24 May 2018 09:06:54 -0400 MIME-Version: 1.0 In-Reply-To: References: <20180522175629.24932-1-richard.henderson@linaro.org> From: Laurent Desnogues Date: Thu, 24 May 2018 15:06:42 +0200 Message-ID: Content-Type: text/plain; charset="UTF-8" Subject: Re: [Qemu-devel] [PATCH] tcg: Fix helper function vs host abi for float16 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Richard Henderson , "qemu-devel@nongnu.org" , qemu-arm On Thu, May 24, 2018 at 2:28 PM, Peter Maydell wrote: > On 23 May 2018 at 06:10, Laurent Desnogues wrote: >> Some AArch64 tests I had that previously failed on a x86-64 host now pass. >> >> Tested-by: Laurent Desnogues > > 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