From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:47800) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8HlI-0004kq-02 for qemu-devel@nongnu.org; Mon, 26 Sep 2011 16:26:48 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R8HlH-00034n-2s for qemu-devel@nongnu.org; Mon, 26 Sep 2011 16:26:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:25399) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R8HlG-00034b-Pt for qemu-devel@nongnu.org; Mon, 26 Sep 2011 16:26:47 -0400 Message-ID: <4E80DFFF.8050403@redhat.com> Date: Mon, 26 Sep 2011 23:26:39 +0300 From: Avi Kivity MIME-Version: 1.0 References: <4E802DDD.8090100@siemens.com> <4E80B944.4040209@redhat.com> <4E80D5EF.4090705@twiddle.net> <4E80D7E9.4050203@redhat.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] tcg: Remove stack protection from helper functions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Peter Maydell Cc: Laurent Desnogues , Jan Kiszka , Mulyadi Santosa , qemu-devel , Richard Henderson On 09/26/2011 11:19 PM, Peter Maydell wrote: > On 26 September 2011 20:52, Avi Kivity wrote: > > Why do floating point ops need helpers? At least if all the edge cases > > match? (i.e. NaNs and denormals) > > The answer is that the edge cases basically never match. Surely they do when host == target. Although there you can virtualize. > No CPU > architecture does handling of NaNs and input denormals and output > denormals and underflow checks and all the rest of it in exactly > the same way as anybody else. (In particular x86 is pretty crazy, > which is unfortunate given that it's the most significant host > arch at the moment.) So any kind of TCG native floating point > support would probably have to translate to "check if either > input is a special case; if not, try the op; check if the output > was a special case; if any of those checks fired, back off to > the softfloat helper function". Which is quite a lot of inline > code, and also annoyingly bouncing between fp ops and integer > bitpattern checks on the fp values. > Alternatively, configure the fpu to trap on these cases, and handle them in a slow path. At least x86 sse allows this (though perhaps not for "quiet NaN"s? Does it matter in practice? Perhaps we can have a fast-and-loose mode for the fpu (gcc does). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.