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.2 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS 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 6DA34C3F2D1 for ; Wed, 4 Mar 2020 18:45:05 +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 3B63D24679 for ; Wed, 4 Mar 2020 18:45:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="c5DufMVU" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 3B63D24679 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38294 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9Z0y-0006qI-E4 for qemu-devel@archiver.kernel.org; Wed, 04 Mar 2020 13:45:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:34030) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9Yzu-0005U1-Cl for qemu-devel@nongnu.org; Wed, 04 Mar 2020 13:43:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9Yzs-0006c8-Vc for qemu-devel@nongnu.org; Wed, 04 Mar 2020 13:43:58 -0500 Received: from mail-lf1-x133.google.com ([2a00:1450:4864:20::133]:42109) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j9Yzs-0006Xg-Kl; Wed, 04 Mar 2020 13:43:56 -0500 Received: by mail-lf1-x133.google.com with SMTP id t21so2366462lfe.9; Wed, 04 Mar 2020 10:43:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=DYiu37dwsk21hL7lcAPw7i5jgwAjbcKdoNnsujluBro=; b=c5DufMVUbtzoM2CNM0S1Xuae+k/CZhUGvfezPeEz0zzoFni3dIunngqvrZ0coEMlDa L5FLjA2ZiMr6KFRukmqkDePMZJatOloGZYhcqWg+PI9V42kOQiDuBMyG47wk2jRfCYwg 97DL/0FCRtOvxzVqqH2WMQsPNK60m+CHZprlfG1/yCg8lXjJPdPEXp4Ri13o/yIatwgP XQqh7tGp7wnDSnx+ZSwkzySuk/tPYdthf/9CX5Gl3jqLtM6CQfNUt0j2r+2E2b++HK2h hFQECW8P9ZFWYegEiDmzUUP5WL74QdXBGrfIFKpwhpt9snm0+nAEGm9fqNfY10Q6qo7b BSuQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=DYiu37dwsk21hL7lcAPw7i5jgwAjbcKdoNnsujluBro=; b=OODFgdcCun5eM8DNDMzPwNSQnG9zZOM8g6TIKGGi1YQ7Xph0jYMtR2aNUY6TkSgqkF KPZTpQab+V8XHgUpEKDG92rBSX85imst7ca75R1r6WOXUh9JA5TvsyILJZF/siUdtpNb 4j7WyiFDgTBZHP9/R9bMS18egaxCzIE+f9qevO4sCx+tIU8HYESmmuFNZpN49tR/QuY8 yIVX8xOP1Fcv8I+hnjDUyvU/xDKpxp9fINbihRYN0IbXwG7WCMjohifELPlHonBZDzOt q3okTKCk6ka6eXeZ0m3t2LYMGu4/jjm/lDagrnrTe+ueh95Tk3bBwyI3SRyoVghaDf4I dXqg== X-Gm-Message-State: ANhLgQ1OilBiIOOBpa7kzf1DR80Xwf3hFshNvqdx/XOl5DTMRIy8i+wd 7dXQNgDJSRAj7Yk9NsEZSh2eoBRE205BxJEYxaA= X-Google-Smtp-Source: ADFU+vtmY0vSOUPfMefj9S93lzD9Ln5TIkBjUEfJWGG7pAqabkb4psq+D8D2WWrWtBlZrtfDmXjvAwJgkfMG0JRbm00= X-Received: by 2002:ac2:532f:: with SMTP id f15mr2769085lfh.3.1583347434048; Wed, 04 Mar 2020 10:43:54 -0800 (PST) MIME-Version: 1.0 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> <878skpxltm.fsf@linaro.org> <2576fd41-8b01-91a0-ca56-792ce65b5092@linaro.org> In-Reply-To: From: G 3 Date: Wed, 4 Mar 2020 13:43:41 -0500 Message-ID: Subject: Fwd: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC To: =?UTF-8?B?QWxleCBCZW5uw6ll?= , Dino Papararo , QEMU Developers , "qemu-ppc@nongnu.org" , Howard Spoelstra , luigi burdo , David Gibson , Aleksandar Markovic Content-Type: multipart/alternative; boundary="0000000000005ccfe105a00bcdd7" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::133 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: , Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --0000000000005ccfe105a00bcdd7 Content-Type: text/plain; charset="UTF-8" ---------- Forwarded message --------- From: G 3 Date: Wed, Mar 4, 2020 at 1:35 PM Subject: Re: [RFC PATCH v2] target/ppc: Enable hardfloat for PPC To: BALATON Zoltan On Mon, Mar 2, 2020 at 6:16 PM BALATON Zoltan wrote: > On Mon, 2 Mar 2020, Richard Henderson wrote: > > On 3/2/20 3:42 AM, BALATON Zoltan wrote: > >>> The "hardfloat" option works (with other targets) only with ieee745 > >>> accumulative exceptions, when the most common of those exceptions, > inexact, has > >>> already been raised. And thus need not be raised a second time. > >> > >> Why exactly it's done that way? What are the differences between IEEE FP > >> implementations that prevents using hardfloat most of the time instead > of only > >> using it in some (although supposedly common) special cases? > > > > While it is possible to read the host's ieee exception word after the > hardfloat > > operation, there are two reasons that is undesirable: > > > > (1) It is *slow*. So slow that it's faster to run the softfloat code > instead. > > I thought it would be easier to find the benchmark numbers that Emilio > > generated when this was tested, but I can't find it. > > I remember those benchmarks too and this is also what the paper Alex > referred to also confirmed. Also I've found that enabling hardfloat for > PPC without doing anything else is slightly slower (on a recent CPU, on > older CPUs could be even slower). Interetingly however it does give a > speedup for vector instructions (maybe because they don't clear flags > between each sub operation). Does that mean these vector instruction > helpers are also buggy regarding exceptions? > I am all intrigued by these vector instructions. Apple was really big on using them back in the day so programs like Quicktime and iTunes definitely use them. I'm not sure if the PowerPC's altivec vector instructions map to host vector instructions already, but if they don't, mapping them would give us a huge speedup in certain places. Would anyone know if this was already done in QEMU? --0000000000005ccfe105a00bcdd7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


---------- Forwarded message ---------
From: G 3 <programmingkidx@gmail.com>Date: Wed, Mar 4, 2020 at 1:35 PM
Subject: Re: [RFC PATCH v2] target/p= pc: Enable hardfloat for PPC
To: BALATON Zoltan <balaton@eik.bme.hu>




On Mon, Mar 2, 2020 at 6:16 PM BALATON Zoltan <= balaton@eik.bme.hu<= /a>> wrote:
O= n Mon, 2 Mar 2020, Richard Henderson wrote:
> On 3/2/20 3:42 AM, BALATON Zoltan wrote:
>>> The "hardfloat" option works (with other targets) on= ly with ieee745
>>> accumulative exceptions, when the most common of those excepti= ons, inexact, has
>>> already been raised.=C2=A0 And thus need not be raised a secon= d time.
>>
>> Why exactly it's done that way? What are the differences betwe= en IEEE FP
>> implementations that prevents using hardfloat most of the time ins= tead of only
>> using it in some (although supposedly common) special cases?
>
> While it is possible to read the host's ieee exception word after = the hardfloat
> operation, there are two reasons that is undesirable:
>
> (1) It is *slow*.=C2=A0 So slow that it's faster to run the softfl= oat code instead.
> I thought it would be easier to find the benchmark numbers that Emilio=
> generated when this was tested, but I can't find it.

I remember those benchmarks too and this is also what the paper Alex
referred to also confirmed. Also I've found that enabling hardfloat for=
PPC without doing anything else is slightly slower (on a recent CPU, on older CPUs could be even slower). Interetingly however it does give a
speedup for vector instructions (maybe because they don't clear flags <= br> between each sub operation). Does that mean these vector instruction
helpers are also buggy regarding exceptions?
--0000000000005ccfe105a00bcdd7--