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 73C6E3888C79 for ; Mon, 14 Nov 2022 19:05:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 73C6E3888C79 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=1668452724; 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=NeJroZBLepvrk6LznNQbJibURx9Ph+S+Zxui1WIOKtk=; b=fKh6yH4nPU21guimjozfS39dcMPERHO2cNeT1LNo7xD0TxrSOvYylxjkGL0/vMTR83DkNf BXKtaCoknhX78Lk0O+HIgm+WM7Fl0xBUcfhX6E2NX1VkHoD4R60f/QsBHYvRc75HEeAo/r sq+mjLThFOQWiEbek0zQUdx90HTGMQQ= Received: from mail-wm1-f72.google.com (mail-wm1-f72.google.com [209.85.128.72]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-644-_BiBuNIlPly56EAIGa53rg-1; Mon, 14 Nov 2022 14:05:22 -0500 X-MC-Unique: _BiBuNIlPly56EAIGa53rg-1 Received: by mail-wm1-f72.google.com with SMTP id j2-20020a05600c1c0200b003cf7397fc9bso7153932wms.5 for ; Mon, 14 Nov 2022 11:05:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:from:references:cc:to:content-language:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=c4rB1jZFG0gvXE6zSpmTlkvQDemOY2ojEdAZeByyGrs=; b=W2EfDyJT0lXqNWmGWBU+dINy46ApRK28U7N8vtGp1GXE4hmUWx0H40wwEZjaZAmvDm gVae2DzavntbZTe+6kg9bxoqcF02UoEEdVspkaBJ2ULzisVqhoPHBKD47q3F4xF+PBjC rSzkLBp9FzXxcQpK75lid+0imqOn1kf9NhuzBixJHSLSrrgQ824vaqeV99+3RzlAq5uR GqlW3ZtZfgofC4ac4/Th+XBh6dsqU6bbmreuxx0JtINUx8wvfZ7cLQnzm727zk0HZ/3Z TN6XCZ9/bGkkQFzxMTUBM0Tv72YkB3Ic8ko56EOCn+bwKhN6GFV4PEuX7zQa95qoPzvA OnJg== X-Gm-Message-State: ANoB5pkX8hZ409jQ331Q2tVQ80uhk6EsYsbC73gVP5bh0b1FMIYcWOmD g1dQhBvu3XPdUvEklv0GT3T1aXyAalHtcVpwsHmr2PWpnUdCXfWZDe8K/+7zDU+DSMIhhbBXa6m Yz1TpUGhuGjgS9oMruQ== X-Received: by 2002:a05:6000:605:b0:236:6f3c:1f2f with SMTP id bn5-20020a056000060500b002366f3c1f2fmr8774266wrb.89.1668452721449; Mon, 14 Nov 2022 11:05:21 -0800 (PST) X-Google-Smtp-Source: AA0mqf4i3WS7X3CInTlXic3h9JG06Y65kVcjLnNMFadXFJUpWsVgLNTaE4KKNeVxc4A+g049BmO+TQ== X-Received: by 2002:a05:6000:605:b0:236:6f3c:1f2f with SMTP id bn5-20020a056000060500b002366f3c1f2fmr8774251wrb.89.1668452721173; Mon, 14 Nov 2022 11:05:21 -0800 (PST) Received: from [192.168.1.2] ([139.47.33.22]) by smtp.gmail.com with ESMTPSA id i11-20020a05600c354b00b003b4ff30e566sm18215223wmq.3.2022.11.14.11.05.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Nov 2022 11:05:20 -0800 (PST) Message-ID: <1ea5fc0e-fcc4-a354-b71b-3da3008ea5f2@redhat.com> Date: Mon, 14 Nov 2022 20:05:19 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.1 Subject: Re: [PATCH] [PR68097] Try to avoid recursing for floats in tree_*_nonnegative_warnv_p. To: Richard Biener Cc: GCC patches , Andrew MacLeod , richard.sandiford@arm.com References: <20221112183048.389811-1-aldyh@redhat.com> From: Aldy Hernandez In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: multipart/mixed; boundary="------------ZezaVmOXXvjudBUmUSKZtlnt" Content-Language: en-US X-Spam-Status: No, score=-10.9 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: This is a multi-part message in MIME format. --------------ZezaVmOXXvjudBUmUSKZtlnt Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 11/14/22 10:12, Richard Biener wrote: > On Sat, Nov 12, 2022 at 7:30 PM Aldy Hernandez wrote: >> >> It irks me that a PR named "we should track ranges for floating-point >> hasn't been closed in this release. This is an attempt to do just >> that. >> >> As mentioned in the PR, even though we track ranges for floats, it has >> been suggested that avoiding recursing through SSA defs in >> gimple_assign_nonnegative_warnv_p is also a goal. We can do this with >> various ranger components without the need for a heavy handed approach >> (i.e. a full ranger). >> >> I have implemented two versions of known_float_sign_p() that answer >> the question whether we definitely know the sign for an operation or a >> tree expression. >> >> Both versions use get_global_range_query, which is a wrapper to query >> global ranges. This means, that no caching or propagation is done. >> In the case of an SSA, we just return the global range for it (think >> SSA_NAME_RANGE_INFO). In the case of a tree code with operands, we >> also use get_global_range_query to resolve the operands, and then call >> into range-ops, which is our lowest level component. There is no >> ranger or gori involved. All we're doing is resolving the operation >> with the ranges passed. >> >> This is enough to avoid recursing in the case where we definitely know >> the sign of a range. Otherwise, we still recurse. >> >> Note that instead of get_global_range_query(), we could use >> get_range_query() which uses a ranger (if active in a pass), or >> get_global_range_query if not. This would allow passes that have an >> active ranger (with enable_ranger) to use a full ranger. These passes >> are currently, VRP, loop unswitching, DOM, loop versioning, etc. If >> no ranger is active, get_range_query defaults to global ranges, so >> there's no additional penalty. >> >> Would this be acceptable, at least enough to close (or rename the PR ;-))? > > I think the checks would belong to the gimple_stmt_nonnegative_warnv_p function > only (that's the SSA name entry from the fold-const.cc ones)? That was my first approach, but I thought I'd cover the unary and binary operators as well, since they had other callers. But I'm happy with just the top-level tweak. It's a lot less code :). > > I also notice the use of 'bool' for the "sign". That's not really > descriptive. We > have SIGNED and UNSIGNED (aka enum signop), not sure if that's the > perfect match vs. NEGATIVE and NONNEGATIVE. Maybe the functions > name is just bad and they should be known_float_negative_p? The bool sign is to keep in line with real.*, and was suggested by Jeff (in real.* not here). I'm happy to change the entire frange API to use sgnop. It is cleaner. If that's acceptable, I could do that as a follow-up. How's this, pending tests once I figure out why my trees have been broken all day :-/. Aldy p.s. First it was sphinx failure, now I'm seeing this: /home/aldyh/src/clean/gcc/match.pd:7935:8 error: return statement not allowed in C expression return NULL_TREE; ^ --------------ZezaVmOXXvjudBUmUSKZtlnt Content-Type: text/x-patch; charset=UTF-8; name="0001-PR68097-Try-to-avoid-recursing-for-floats-in-gimple_.patch" Content-Disposition: attachment; filename*0="0001-PR68097-Try-to-avoid-recursing-for-floats-in-gimple_.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA2ZTM2NjI2YWVjODFiZjk3ZjhmNTQxMTZhMjkxNTc0YzE2Y2JjMjA1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBBbGR5IEhlcm5hbmRleiA8YWxkeWhAcmVkaGF0LmNvbT4KRGF0 ZTogU2F0LCAxMiBOb3YgMjAyMiAxMTo1ODowNyArMDEwMApTdWJqZWN0OiBbUEFUQ0hdIFtQUjY4 MDk3XSBUcnkgdG8gYXZvaWQgcmVjdXJzaW5nIGZvciBmbG9hdHMgaW4KIGdpbXBsZV9zdG10X25v bm5lZ2F0aXZlX3dhcm52X3AuCgpJdCBpcmtzIG1lIHRoYXQgYSBQUiBuYW1lZCAid2Ugc2hvdWxk IHRyYWNrIHJhbmdlcyBmb3IgZmxvYXRpbmctcG9pbnQKaGFzbid0IGJlZW4gY2xvc2VkIGluIHRo aXMgcmVsZWFzZS4gIFRoaXMgaXMgYW4gYXR0ZW1wdCB0byBkbyBqdXN0CnRoYXQuCgpBcyBtZW50 aW9uZWQgaW4gdGhlIFBSLCBldmVuIHRob3VnaCB3ZSB0cmFjayByYW5nZXMgZm9yIGZsb2F0cywg aXQgaGFzCmJlZW4gc3VnZ2VzdGVkIHRoYXQgYXZvaWRpbmcgcmVjdXJzaW5nIHRocm91Z2ggU1NB IGRlZnMgaW4KZ2ltcGxlX2Fzc2lnbl9ub25uZWdhdGl2ZV93YXJudl9wIGlzIGFsc28gYSBnb2Fs LiAgVGhpcyBwYXRjaCB1c2VzIGEKZ2xvYmFsIHJhbmdlIHF1ZXJ5IChubyBvbi1kZW1hbmQgbG9v a3VwcywganVzdCBnbG9iYWwgcmFuZ2VzIGFuZAptaW5pbWFsIGZvbGRpbmcpIHRvIGRldGVybWlu ZSBpZiB0aGUgcmFuZ2Ugb2YgYSBzdGF0ZW1lbnQgaXMga25vd24gdG8KYmUgbm9uLW5lZ2F0aXZl LgoKCVBSIHRyZWUtb3B0aW1pemF0aW9uLzY4MDk3CgpnY2MvQ2hhbmdlTG9nOgoKCSogZ2ltcGxl LWZvbGQuY2MgKGdpbXBsZV9zdG10X25vbm5lZ2F0aXZlX3dhcm52X3ApOiBDYWxsCglyYW5nZV9v Zl9zdG10IGZvciBmbG9hdHMuCi0tLQogZ2NjL2dpbXBsZS1mb2xkLmNjIHwgMTAgKysrKysrKysr KwogMSBmaWxlIGNoYW5nZWQsIDEwIGluc2VydGlvbnMoKykKCmRpZmYgLS1naXQgYS9nY2MvZ2lt cGxlLWZvbGQuY2MgYi9nY2MvZ2ltcGxlLWZvbGQuY2MKaW5kZXggMGEyMTJlNmQwZDQuLjc5Y2M0 ZDdmNTY5IDEwMDY0NAotLS0gYS9nY2MvZ2ltcGxlLWZvbGQuY2MKKysrIGIvZ2NjL2dpbXBsZS1m b2xkLmNjCkBAIC02OCw2ICs2OCw3IEBAIGFsb25nIHdpdGggR0NDOyBzZWUgdGhlIGZpbGUgQ09Q WUlORzMuICBJZiBub3Qgc2VlCiAjaW5jbHVkZSAidHJlZS1zc2Etc3RybGVuLmgiCiAjaW5jbHVk ZSAidmFyYXNtLmgiCiAjaW5jbHVkZSAiaW50ZXJuYWwtZm4uaCIKKyNpbmNsdWRlICJnaW1wbGUt cmFuZ2UuaCIKIAogZW51bSBzdHJsZW5fcmFuZ2Vfa2luZCB7CiAgIC8qIENvbXB1dGUgdGhlIGV4 YWN0IGNvbnN0YW50IHN0cmluZyBsZW5ndGguICAqLwpAQCAtOTIzNCw2ICs5MjM1LDE1IEBAIGJv b2wKIGdpbXBsZV9zdG10X25vbm5lZ2F0aXZlX3dhcm52X3AgKGdpbXBsZSAqc3RtdCwgYm9vbCAq c3RyaWN0X292ZXJmbG93X3AsCiAJCQkJIGludCBkZXB0aCkKIHsKKyAgdHJlZSB0eXBlID0gZ2lt cGxlX3JhbmdlX3R5cGUgKHN0bXQpOworICBpZiAodHlwZSAmJiBmcmFuZ2U6OnN1cHBvcnRzX3Ag KHR5cGUpKQorICAgIHsKKyAgICAgIGZyYW5nZSByOworICAgICAgYm9vbCBzaWduOworICAgICAg cmV0dXJuIChnZXRfZ2xvYmFsX3JhbmdlX3F1ZXJ5ICgpLT5yYW5nZV9vZl9zdG10IChyLCBzdG10 KQorCSAgICAgICYmIHIuc2lnbmJpdF9wIChzaWduKQorCSAgICAgICYmIHNpZ24gPT0gZmFsc2Up OworICAgIH0KICAgc3dpdGNoIChnaW1wbGVfY29kZSAoc3RtdCkpCiAgICAgewogICAgIGNhc2Ug R0lNUExFX0FTU0lHTjoKLS0gCjIuMzguMQoK --------------ZezaVmOXXvjudBUmUSKZtlnt--