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 4D9533858D37 for ; Tue, 20 Sep 2022 05:22:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4D9533858D37 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=1663651338; h=from:from: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=6n7I3u9QqQllH/qpx5bIDsSbTSdrDiMlKgFc0UEDoc0=; b=WnffvX19gVovSP3HeWluMDPAlIcTomMwwUOFBg5oTnBVHKiVRhcLpnunetuZMUokRluzon p9K3VV5laE+Akhtd+7Zu2kSLxz3eqVeM06Sa2Nla/PkuJzHJ0YgbPhQGGInealS6S562dY fgV2FyOfwEVfAdYn20WP5VhX3dPomXE= Received: from mail-ot1-f72.google.com (mail-ot1-f72.google.com [209.85.210.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-562-VtIHwvjbOTaOl1KDDXHfLw-1; Tue, 20 Sep 2022 01:22:16 -0400 X-MC-Unique: VtIHwvjbOTaOl1KDDXHfLw-1 Received: by mail-ot1-f72.google.com with SMTP id f13-20020a056830056d00b006549b545aa6so838479otc.0 for ; Mon, 19 Sep 2022 22:22:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=6n7I3u9QqQllH/qpx5bIDsSbTSdrDiMlKgFc0UEDoc0=; b=mGLyAOpIWwqY8Uap6pdIm8ZERweHfBu1lQKRvnK+yLASoQuopxuRnPBTLDvTkRjjtJ EeC6CxT5FXcdotntTZaLqsNnAqgGND7fRBe4Vgzy90ZJnvCzBOyg3fxmDGPcamJHa2Pi f5dFUQzaQgAsTKLpmDzlp96rLr/uY/EMij3/EXKbFWE7IIcHCN5Z+L2qxgaMZ+NvlXjw QLNk0cYQyxOrVqTW+ylyLVUgRdeo2pK0R+dLCsQSnwsFIYJUkawvJRyPesI+3izJo6ET 3Sqwei9Ju6AoGDeQxh21EtlZo6fbaL2NQbVBc29oDrIcdd/d+DQWfu1ZEvJObEjprmi5 S3Xw== X-Gm-Message-State: ACrzQf1EPY1JFjvV10759CaXBywMSUQ6hFo7NHHKrhShD+3alokzG5tL OvENEeLINFBIVNgKKQ7xkDO8wIsLgBzQgnLI1TcLL8nbYZaz0mHplVhPnIeOlzwMCiiBY2XSDMu 15moMFgXf+jWFwjLlpcoEYruTqFVTcmO0Hg== X-Received: by 2002:a9d:4709:0:b0:655:b51e:fc6a with SMTP id a9-20020a9d4709000000b00655b51efc6amr9840146otf.276.1663651335461; Mon, 19 Sep 2022 22:22:15 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4DwVaAl4Ilm/IQWE4IA7jxbLfUk4EablB2gpEHbI381EoQkkKHa4ONcn3UuvP1f47sDU/7wVH/T6K4i5TRTV8= X-Received: by 2002:a9d:4709:0:b0:655:b51e:fc6a with SMTP id a9-20020a9d4709000000b00655b51efc6amr9840137otf.276.1663651335143; Mon, 19 Sep 2022 22:22:15 -0700 (PDT) MIME-Version: 1.0 References: <20220917082403.1573721-1-aldyh@redhat.com> In-Reply-To: From: Aldy Hernandez Date: Tue, 20 Sep 2022 07:22:03 +0200 Message-ID: Subject: Re: [PATCH] frange: flush denormals to zero for -funsafe-math-optimizations. To: Richard Biener Cc: Jakub Jelinek , Richard Henderson , GCC patches X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="000000000000dcb1d905e915025d" X-Spam-Status: No, score=-11.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,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: --000000000000dcb1d905e915025d Content-Type: text/plain; charset="UTF-8" On Mon, Sep 19, 2022 at 3:45 PM Richard Biener wrote: > > On Mon, Sep 19, 2022 at 3:04 PM Aldy Hernandez wrote: > > > > On Mon, Sep 19, 2022 at 9:37 AM 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? > > > > > > 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 might also be a correctness requirement in case we don't know how > > > targets handle denormals (IIRC even OS defaults might matter here) so > > > we conservatively have to treat them as being flushed to zero. > > > > Actually, rth suggested we always flush to zero because we don't know > > what the target would do. Again, I'm happy to do whatever you agree > > on. I have no opinion. My main goal here is correctness. > > Yes, I think we should do this. Ok, I'm pushing the attached patch because it's conservatively correct everywhere. We can tweak it when y'all reach consensus. > > > > > > > So ... if we want to be on the "safe" side then please always do this. > > > > > > At the same point you could do > > > > > > if (!HONOR_SIGNED_ZEROS ()) > > > if (real_iszero (&m_max)) > > > { > > > if (real_iszero (&m_min)) > > > m.min.sign = 1; > > > m_max.sign = 1; > > > } > > > > But wouldn't that set [-0.0, -0.0] when encountering [+0, +0] ?? > > Yeah, that's my laziness not adding a special case for m_min == m_max. > > > > > > else if (real_iszero (&m_min)) > > > m_min.sign = 0; > > > > Jakub actually suggested something completely different...just set +0 > > always for !HONOR_SIGNED_ZEROS. > > Hmm, but the [-1, -0.] with known sign becomes [-1, +0.] with unknown sign? Huh. I guess that's true. Does that happen often enough in practice to matter? I suppose we're going into uncharted territory with folks asking for no signs on zeros, but them appearing in the source code? My gut feeling is that we should take whatever signs are in the source code (similar to what we're doing for NANs), but don't introduce any additional ones. Again, no strong opinions. Feel free to add whatever adjustment you think is necessary. Aldy --000000000000dcb1d905e915025d Content-Type: text/x-patch; charset="US-ASCII"; name="0001-frange-flush-denormals-to-zero.patch" Content-Disposition: attachment; filename="0001-frange-flush-denormals-to-zero.patch" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_l89r0t8l0 RnJvbSAyYjYxZWQ4MzhjN2YzZjRiZjU0ZDQ1MzBjMGYwNTNiNDIwNjIzYmViIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGR5IEhlcm5hbmRleiA8YWxkeWhAcmVkaGF0LmNvbT4KRGF0 ZTogU2F0LCAxNyBTZXAgMjAyMiAxMDoxNzoxMyArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIGZyYW5n ZTogZmx1c2ggZGVub3JtYWxzIHRvIHplcm8KCkZvciBzb21lIGFyY2hpdGVjdHVyZXMgKG9yIGZv ciAtZnVuc2FmZS1tYXRoLW9wdGltaXphdGlvbnMpIHdlIG1heQpmbHVzaCBkZW5vcm1hbHMgdG8g emVybywgaW4gd2hpY2ggY2FzZSB3ZSBuZWVkIHRvIGJlIGNhcmVmdWwgdG8KZXh0ZW5kIHRoZSBy YW5nZXMgdG8gdGhlIGFwcHJvcHJpYXRlIHplcm8uICBUaGlzIHBhdGNoIGRvZXMgZXhhY3RseSB0 aGF0LgpGb3IgYSByYW5nZSBvZiBbeCwgLURFTk9STUFMXSB3ZSBmbHVzaCB0byBbeCwgLTAuMF0g YW5kIGZvciBbK0RFTk9STUFMLCB4XQp3ZSBmbHVzaCB0byBbKzAuMCwgeF0uCgpnY2MvQ2hhbmdl TG9nOgoKCSogdmFsdWUtcmFuZ2UuY2MgKGZyYW5nZTo6Zmx1c2hfZGVub3JtYWxzX3RvX3plcm8p OiBOZXcuCgkoZnJhbmdlOjpzZXQpOiBDYWxsIGZsdXNoX2Rlbm9ybWFsc190b196ZXJvLgoJKiB2 YWx1ZS1yYW5nZS5oIChjbGFzcyBmcmFuZ2UpOiBBZGQgZmx1c2hfZGVub3JtYWxzX3RvX3plcm8u Ci0tLQogZ2NjL3ZhbHVlLXJhbmdlLmNjIHwgMjMgKysrKysrKysrKysrKysrKysrKysrKysKIGdj Yy92YWx1ZS1yYW5nZS5oICB8ICAxICsKIDIgZmlsZXMgY2hhbmdlZCwgMjQgaW5zZXJ0aW9ucygr KQoKZGlmZiAtLWdpdCBhL2djYy92YWx1ZS1yYW5nZS5jYyBiL2djYy92YWx1ZS1yYW5nZS5jYwpp bmRleCA2N2Q1ZDdmYTkwZi4uYThlM2JiMzliYWIgMTAwNjQ0Ci0tLSBhL2djYy92YWx1ZS1yYW5n ZS5jYworKysgYi9nY2MvdmFsdWUtcmFuZ2UuY2MKQEAgLTI2Nyw2ICsyNjcsMjYgQEAgdHJlZV9j b21wYXJlICh0cmVlX2NvZGUgY29kZSwgdHJlZSBvcDEsIHRyZWUgb3AyKQogICByZXR1cm4gIWlu dGVnZXJfemVyb3AgKGZvbGRfYnVpbGQyIChjb2RlLCBpbnRlZ2VyX3R5cGVfbm9kZSwgb3AxLCBv cDIpKTsKIH0KIAorLy8gRmx1c2ggZGVub3JtYWwgZW5kcG9pbnRzIHRvIHRoZSBhcHByb3ByaWF0 ZSAwLjAuCisKK3ZvaWQKK2ZyYW5nZTo6Zmx1c2hfZGVub3JtYWxzX3RvX3plcm8gKCkKK3sKKyAg aWYgKHVuZGVmaW5lZF9wICgpIHx8IGtub3duX2lzbmFuICgpKQorICAgIHJldHVybjsKKworICAv LyBGbHVzaCBbeCwgLURFTk9STUFMXSB0byBbeCwgLTAuMF0uCisgIGlmIChyZWFsX2lzZGVub3Jt YWwgKCZtX21heCkgJiYgcmVhbF9pc25lZyAoJm1fbWF4KSkKKyAgICB7CisgICAgICBtX21heCA9 IGRjb25zdDA7CisgICAgICBpZiAoSE9OT1JfU0lHTkVEX1pFUk9TIChtX3R5cGUpKQorCW1fbWF4 LnNpZ24gPSAxOworICAgIH0KKyAgLy8gRmx1c2ggWytERU5PUk1BTCwgeF0gdG8gWyswLjAsIHhd LgorICBpZiAocmVhbF9pc2Rlbm9ybWFsICgmbV9taW4pICYmICFyZWFsX2lzbmVnICgmbV9taW4p KQorICAgIG1fbWluID0gZGNvbnN0MDsKK30KKwogLy8gU2V0dGVyIGZvciBmcmFuZ2VzLgogCiB2 b2lkCkBAIC0zMTcsNiArMzM3LDkgQEAgZnJhbmdlOjpzZXQgKHRyZWUgbWluLCB0cmVlIG1heCwg dmFsdWVfcmFuZ2Vfa2luZCBraW5kKQogICBnY2NfY2hlY2tpbmdfYXNzZXJ0ICh0cmVlX2NvbXBh cmUgKExFX0VYUFIsIG1pbiwgbWF4KSk7CiAKICAgbm9ybWFsaXplX2tpbmQgKCk7CisKKyAgZmx1 c2hfZGVub3JtYWxzX3RvX3plcm8gKCk7CisKICAgaWYgKGZsYWdfY2hlY2tpbmcpCiAgICAgdmVy aWZ5X3JhbmdlICgpOwogfQpkaWZmIC0tZ2l0IGEvZ2NjL3ZhbHVlLXJhbmdlLmggYi9nY2MvdmFs dWUtcmFuZ2UuaAppbmRleCAzYTQwMWYzZTRlMi4uNzk1YjFmMDBmZGMgMTAwNjQ0Ci0tLSBhL2dj Yy92YWx1ZS1yYW5nZS5oCisrKyBiL2djYy92YWx1ZS1yYW5nZS5oCkBAIC0zMjcsNiArMzI3LDcg QEAgcHJpdmF0ZToKICAgYm9vbCB1bmlvbl9uYW5zIChjb25zdCBmcmFuZ2UgJik7CiAgIGJvb2wg aW50ZXJzZWN0X25hbnMgKGNvbnN0IGZyYW5nZSAmKTsKICAgYm9vbCBjb21iaW5lX3plcm9zIChj b25zdCBmcmFuZ2UgJiwgYm9vbCB1bmlvbl9wKTsKKyAgdm9pZCBmbHVzaF9kZW5vcm1hbHNfdG9f emVybyAoKTsKIAogICB0cmVlIG1fdHlwZTsKICAgUkVBTF9WQUxVRV9UWVBFIG1fbWluOwotLSAK Mi4zNy4xCgo= --000000000000dcb1d905e915025d--