From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7F06AC4BA3B for ; Thu, 27 Feb 2020 11:56:26 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4FBD624692 for ; Thu, 27 Feb 2020 11:56:26 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4FBD624692 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=eik.bme.hu Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:58066 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7HmD-00023h-Ei for qemu-devel@archiver.kernel.org; Thu, 27 Feb 2020 06:56:25 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51180) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j7Hkt-0008Du-ME for qemu-devel@nongnu.org; Thu, 27 Feb 2020 06:55:04 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j7Hkr-0001XF-W0 for qemu-devel@nongnu.org; Thu, 27 Feb 2020 06:55:03 -0500 Received: from zero.eik.bme.hu ([152.66.115.2]:59653) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j7Hkq-0001Li-8Z; Thu, 27 Feb 2020 06:55:00 -0500 Received: from zero.eik.bme.hu (blah.eik.bme.hu [152.66.115.182]) by localhost (Postfix) with SMTP id A28737475F6; Thu, 27 Feb 2020 12:54:58 +0100 (CET) Received: by zero.eik.bme.hu (Postfix, from userid 432) id 844137461AE; Thu, 27 Feb 2020 12:54:58 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by zero.eik.bme.hu (Postfix) with ESMTP id 82B5874569F; Thu, 27 Feb 2020 12:54:58 +0100 (CET) Date: Thu, 27 Feb 2020 12:54:58 +0100 (CET) From: BALATON Zoltan To: Aleksandar Markovic Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC In-Reply-To: Message-ID: References: <20200218171702.979F074637D@zero.eik.bme.hu> <1BC2E9E9-A694-4ED3-BD3D-D731F23B7245@gmail.com> <3539F747-145F-49CC-B494-C9794A8ABABA@gmail.com> <87eeuhxw0y.fsf@linaro.org> <2126C4B4-B0F2-4B0F-ADEC-211466989E36@gmail.com> User-Agent: Alpine 2.22 (BSF 395 2020-01-19) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 152.66.115.2 X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Dino Papararo , QEMU Developers , Programmingkid , "qemu-ppc@nongnu.org" , Howard Spoelstra , luigi burdo , =?ISO-8859-15?Q?Alex_Benn=E9e?= , David Gibson Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, 27 Feb 2020, Aleksandar Markovic wrote: > I totally disagree with your using the term "hardfloat feature enabled" in > this context, speaking about this particulat patch. This may be just > wishful thinking. The right wording would be "hardfloat feature hacked", or > "hardfloat feature fooled". > > The patch itself has the wrong, intentionally misleading and confusing > title from the outset. It should be something like "target/ppc: Cheat > hardfloat feature into beleiving that inexact flag is always set" May I point out that the patch is RFC, meaning it's not meant to be merged only to test it and provide feedback. Also the limitations were stated in the commit message. There's no other easy way that I know to test if hardfloat would work with PPC than forcing inexact bit to have it run with hardfloat most of the time. Once it's tested what regression this would cause (other than the expected inexact bit) then we can see if there are any other problem with hardfloat and PPC or only this bit. Then we can either change it to only not clear inexact bit like it's done on other archs or do something else as even not clearing sticky inexact bit would break the non-sticky counterpart PPC has. Breakage would be limited to the non-sticky version and discussion was about if even that's unacceptable. Regards, BALATON Zoltan