From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by sourceware.org (Postfix) with ESMTPS id 7AD243858D1E for ; Mon, 6 May 2024 17:08:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7AD243858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 7AD243858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::430 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715015331; cv=none; b=sMVWaYifOnGrvh40ff+pn2pElPqr9LOu+dR/N9f3koHlK1u1rljnKiCACE/CXpYSHFuIS+nQP52YlSZ5haZN35P9HjST/6kDha/RmAwefjkoJKLZ8EvdDILbJPmrGcbG0ciT9ThUElFnThErxSgcd09AuoN6WOMv25evSdY2D5w= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1715015331; c=relaxed/simple; bh=HICSQ5thyAZxFDSq/Ei/ZPUnkRdu+Sa23Vn4m5+QwdU=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=LNrZWg78+puKPyQF9SW8cYvzI1uI1/qOquqfxmBU2EAQ1jEICs4CEuS5Jq8/iYE/7WDMk9gpfraLnpy5cwbTFpYCloUpoonL88fg4ipunu17oQ//FUS72O3OKuZu2SJgKrlJ92tjw9qOUJitoq2f34OTq89Y8bTgu9EXDT9KdqU= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-6f447260f9dso1449692b3a.0 for ; Mon, 06 May 2024 10:08:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1715015324; x=1715620124; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=Ka6RafEs3WSsUB46+992erpJZOSDuKOOd6aG2zRwgMc=; b=vSFsdgJGEj9P1+52ysqsum9CMWf4nFrVweyE9gFHGe6/ib/Qh1ZggOtkycQD031R9F pGRi8WpxvXXdtHmfrFdgDB0XEr5scY1Vxf+uocuYTUJ6MdpMIydm6/ZOU6g0j8VaLkuQ R21v44TT1SWn57ilwfyoAJnbYSDn+6TAYJbHMYsUov2cneFd48wmbTLDIjDvbrYebzjt tZGrRxH1hGrKKPMu+otdowIFPEAp8UMcUKAwxEyRdCObx18r3Qlo66bVpe3CtSnBHExG na79W+B4Dup4r04/JMnPpEJkU3XoYygJMG3zuYGqzJCTmnEUcYcthqkNTqklRMqXggOg W8Uw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715015324; x=1715620124; h=content-transfer-encoding:in-reply-to:organization:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Ka6RafEs3WSsUB46+992erpJZOSDuKOOd6aG2zRwgMc=; b=f+kp0IDysnyL0yyu7cs578xPusbXGkPR0AocCbDa5zr7ZMy4B7gF4ynYTta1/s6wX3 5USEajQC3F8VeAbBpVtoEUFqtaHjXv8twAtjX+asvm2xcbXb8DuYaDJFxnrmQVQtugRz TlrBnHY44q2VjsWn1wH0cLoajd1ukdWLrC5e9RaTa4U7UU+heesIlqV820CGgx95xd9Z vCqzGD4NcQiaI80gIAEGzg6/WwCg4o3VI94OUOGd1e2EhUVpJPZO1lJJzkNcTSrXEJRb xcBAqcKsKbtEudPQsRg1RgPxSzjzSz03pSHf8kW/fczzub5LGnhLHerDTJ2nh3brU6fu qw1w== X-Forwarded-Encrypted: i=1; AJvYcCWmqOP9ZpyXrjaGLYlW2lyN/1npdnOw/LDZG7v6FKMtX1OYFcAA8yIHcn6+6f/EH6cZ55XMK6Au5VSauv7b3HZ1JNxHch1nLkAr X-Gm-Message-State: AOJu0YzC6uhcJgcDKLdMJkofvctgHa6F87e6kraJ7nsceZ56jut3u4dz jrdWxog/IiHAkGTEzej7PBvLrD8R+17Ds55n1MB/e1n9rGFz6DLFM84/u8QK5Q4= X-Google-Smtp-Source: AGHT+IEKrImAA2+FnAMg/8Lf+aiZk/jmNvOb5fZkXUPcF5piTmoRa9kl7PZAhKgHD5rAxwJ2MT/gXQ== X-Received: by 2002:a05:6a00:10ca:b0:6f3:34c0:13c9 with SMTP id d10-20020a056a0010ca00b006f334c013c9mr10868333pfu.29.1715015324188; Mon, 06 May 2024 10:08:44 -0700 (PDT) Received: from [192.168.15.31] ([191.13.195.113]) by smtp.gmail.com with ESMTPSA id fh37-20020a056a00392500b006eac2a25631sm7925043pfb.129.2024.05.06.10.08.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 06 May 2024 10:08:42 -0700 (PDT) Message-ID: Date: Mon, 6 May 2024 14:08:39 -0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] powerpc: Fix __fesetround_inline_nocheck on POWER9+ (BZ 31682) To: Paul E Murphy , libc-alpha@sourceware.org Cc: Manjunath S Matti , Peter Bergner References: <20240430124011.12408-1-adhemerval.zanella@linaro.org> <17f748c4-399e-4f8a-9a62-a9b86f7a0aae@linaro.org> <4daa27e7-159f-4bf2-a682-5fd6bd00ad47@linux.ibm.com> <103f99dd-ac9e-4193-b67d-99d0e5f3eb9e@linaro.org> Content-Language: en-US From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-5.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_LOTSOFHASH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 03/05/24 15:30, Paul E Murphy wrote: > > > On 5/1/24 9:01 AM, Adhemerval Zanella Netto wrote: >> >> >> On 30/04/24 18:58, Paul E Murphy wrote: >>> >>> >>> On 4/30/24 1:34 PM, Adhemerval Zanella Netto wrote: >>>> >>>> >>>> On 30/04/24 15:13, Paul E Murphy wrote: >>>>> >>>>> >>>>> On 4/30/24 7:40 AM, Adhemerval Zanella wrote: >>>>>> The e68b1151f7460d5fa88c3a567c13f66052da79a7 commit changed the >>>>>> __fesetround_inline_nocheck implementation to use mffscrni >>>>>> (through __fe_mffscrn) instead of mtfsfi.  For generic powerpc >>>>>> ceil/floor/trunc, the function is supposed to not change the >>>>>> Floating-Point Inexact Exception Enable bit, however mffscrni >>>>>> clear bits 56:63 (VE, OE, UE, ZE, XE, NI, RN), different than mtfsfi. >>>>> >>>>> I don't think that explanation is correct. mffscrni should not alter the exception enable bits. It copies them into FRT, but does not clear them. >>>> >>>> Yeah, I forgot to add that mffscrni in this context clears because >>>> there is no easy way to mask out the current bits 56:63 since only >>>> the rounding bit is provided.  So maybe: >>>> >>>>     The e68b1151f7460d5fa88c3a567c13f66052da79a7 commit changed the >>>>     __fesetround_inline_nocheck implementation to use mffscrni >>>>     (through __fe_mffscrn) instead of mtfsfi.  For generic powerpc >>>>     ceil/floor/trunc, the function is supposed to not change the >>>>     Floating-Point Inexact Exception Enable bit, however mffscrni >>>>     usage always clear the the bits 56:63 (VE, OE, UE, ZE, XE, NI, RN), >>>>     since only the rounding mode is provided. >>> >>> I think the comment has mtfsfi and mffscrni swapped.  The usage of mtfsfi clears bits 60 (XE) and 61 (NI) of the fpscr.  mffscrni does not alter any fpscr bits besides RN. >>> >>> Should __fesetround_inline_nocheck be removed in favor of using __fesetround_inline?  The description of __fesetround_inline_nocheck is confusing. It fails to mention that XE and NI are cleared, as implied by the usage of mtfsfi. >> The main issue is the use of __fe_mffscrn on POWER9, below it is a striped >> testcase from the generic ceil.  If you run by building against POWER8: >> >> $ powerpc64le-glibc-linux-gnu-gcc -O2 -g -std=gnu11 -mcpu=power8 -D_GNU_SOURCE test.c -o test-pwr8 -lm >> $ ./test-pwr8 >> 0000000000000000000000000000000000000000000000000000000000001000 >> 0000000000000000000000000000000000000000000000000000000000000010 >> >> Now with POWER9: >> $ powerpc64le-glibc-linux-gnu-gcc -O2 -g -std=gnu11 -mcpu=power9 -D_GNU_SOURCE test.c -o test-pwr9 -lm >> $ ./test-pwr9 >> 0000000000000000000000000000000000000000000000000000000000001000 >> 0000000000000000000000000000000000000000000000000000000000001010 >> Floating point exception >> >> You can see that for POWER8, the XE bits it cleared as expected by >> __fesetround_inline_nocheck (because ceil/floor/trunc should not trigger >> any floating-point exception), while for POWER9, as you said, only the >> rounding bits are changed. > > The commit message is still hard to digest.  The caller expects the inexact exception to be disable upon return.  mffscrni does not change any exception enable bits.  Can you also update the description (and maybe name) of the function to explicitly state this?  Likewise, note that we expect the NI bit to be 0 always. I give you that both the name and its description is ideal, I will update the patch. > > Otherwise, this patch LGTM.