From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id C7CA53858D32 for ; Mon, 19 Sep 2022 08:26:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C7CA53858D32 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663575963; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=pRmZQ3pHxlw+MXxLkECc59WZDNU7NQZBAVSRwk4+YGw=; b=fnoWTtVJalo8C7PpijizwGjcgAhxHwPiLSd5aXn26DL4viB3fiUIy3kVeFDErrO5ygO2z1 /lXR3hdkA70tgZNto8EN/iRPa4KEcGf6Z2vmgCz65dyaQ4fsKynik4OqwjbXxNKbj6pxFG 1wXkP+Xa0gpVwQi06PdmoHLhuQy6/2Q= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-82-cYN4sTAmOFavMeR5Vvw-mA-1; Mon, 19 Sep 2022 04:26:00 -0400 X-MC-Unique: cYN4sTAmOFavMeR5Vvw-mA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3F9D81C07583; Mon, 19 Sep 2022 08:26:00 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.194]) by smtp.corp.redhat.com (Postfix) with ESMTPS id EC0AF2087440; Mon, 19 Sep 2022 08:25:59 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 28J8PvuW641494 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 19 Sep 2022 10:25:57 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 28J8Puhl641493; Mon, 19 Sep 2022 10:25:56 +0200 Date: Mon, 19 Sep 2022 10:25:56 +0200 From: Jakub Jelinek To: Richard Biener Cc: Aldy Hernandez , Richard Henderson , GCC patches Subject: Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations. Message-ID: Reply-To: Jakub Jelinek References: <20220917082403.1573721-1-aldyh@redhat.com> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=unavailable 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 Mon, Sep 19, 2022 at 09:37:22AM +0200, Richard Biener wrote: > On Sat, Sep 17, 2022 at 10:25 AM Aldy Hernandez via Gcc-patches > wrote: > > > > Jakub has mentioned that for -funsafe-math-optimizations we may flush > > denormals to zero, in which case we need to be careful to extend the > > ranges to the appropriate zero. This patch does exactly that. For a > > range of [x, -DENORMAL] we flush to [x, -0.0] and for [+DENORMAL, x] > > we flush to [+0.0, x]. > > > > It is unclear whether we should do this for Alpha, since I believe > > flushing to zero is the default, and the port requires -mieee for IEEE > > sanity. If so, perhaps we should add a target hook so backends are > > free to request flushing to zero. > > > > Thoughts? > > I'm not sure what the intention of this is - it effectively results in > more conservative ranges for -funsafe-math-optimizations. That is, > if -funsafe-math-optimizations says that denormals don't exist and > are all zero then doesn't that mean we can instead use the smalles > non-denormal number less than (or greater than) zero here? Yes, with -funsafe-math-optimizations we will sometimes have slightly larger ranges, while when we know or assume we know that denormals will be honored we can be more precise. It is similar to the -fno-signed-zeros case, when we are more relaxed and say we don't care about sign of zeros and optimizations can be performed to leave the sign of zero in whatever state they like, we can't have [+0.0, xx] or [xx, -0.0] ranges and need to extend them to [-0.0, xx] or [xx, +0.0]. The honor denormals case is similar, if there is the possibility of having denormals flushed to zero, [+denormal, xx] needs to be extended to [+0.0, xx] and [xx, -denormal] to [xx, -0.0]. Now, I think we just should add a separate option whether denormals are honored or not, because always extending the ranges with denormals on the boundaries might prevent some useful optimizations. If we add such an option, it could default to not honoring them for -funsafe-math-optimizations, and say on alpha it should default to not honoring them by default always unless -mieee option is used, but all of this if the user didn't use the option explicitly, in that case follow what the user said. That way if users know they set DTZ flag themselves or use libraries that do so, they can tell the compiler about it. > That said, the flushing you do is also "valid" for > -fno-unsafe-math-optimizations > in case we don't want to deal with denormals in range boundaries. It is always valid to extend the range more, but could be harmful to optimizations. Say if we have then x > 0.0 test... Of course, without -ffast-math we won't DCE various floating point operations because they can raise exceptions, but at least we can DCE the basic block after it that depends on x > 0.0. Jakub