From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9507 invoked by alias); 4 Dec 2017 05:55:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 9497 invoked by uid 89); 4 Dec 2017 05:55:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-25.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=Hx-languages-length:1796 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Dec 2017 05:55:30 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 654FAC047B67 for ; Mon, 4 Dec 2017 05:55:29 +0000 (UTC) Received: from localhost.localdomain (ovpn-112-2.rdu2.redhat.com [10.10.112.2]) by smtp.corp.redhat.com (Postfix) with ESMTP id E01A461982 for ; Mon, 4 Dec 2017 05:55:28 +0000 (UTC) From: Jeff Law To: gcc-patches Subject: [RFA][PATCH][tree-optimization/78496] 01/03 Do not lose range information from earlier VRP passes Message-ID: Date: Mon, 04 Dec 2017 05:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------04151DEF5DE3748028D234C2" X-IsSubscribed: yes X-SW-Source: 2017-12/txt/msg00118.txt.bz2 This is a multi-part message in MIME format. --------------04151DEF5DE3748028D234C2 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-length: 995 As we touched on in IRC, the EVRP analyzer was doing something stupid which caused it to not merge in existing range information under certain circumstances. Consider this fragment: x_1 = foo () if (x_1 > 2) __builtin_unreachable (); if (x_1 < 0) __builtin_unreachable (); Obviously the range for x_1 is [0,2] and we compute that range in the EVRP optimization pass as well as VRP. If a pass (say VRP) were to delete the __builtin_unreachable calls we'll be left with: x_1 = foo () Any subsequent EVRP analysis won't be able to generate range information for that statement -- ie, it looks like VR_VARYING. Due to a dumb bug in the EVRP analysis we allowed that VR_VARYING to override any range that had been computed by an earlier VRP or EVRP pass. Fixing is trivial. Always call update_value_range, even if the currently discovered range is VR_VARYING. Bootstrapped and regression tested, both in isolation and as part of this 3 part kit. OK for the trunk? Jeff --------------04151DEF5DE3748028D234C2 Content-Type: text/plain; charset=UTF-8; name="P1" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="P1" Content-length: 1037 CSogZ2ltcGxlLXNzYS1ldnJwLWFuYWx5emUuYwoJKGV2cnBfcmFuZ2VfYW5h bHl6ZXI6OmV4dHJhY3RfcmFuZ2VfZnJvbV9zdG10KTogIEFsd2F5cyB1c2UK CXZyX3ZhbHVlczo6dXBkYXRlX3ZhbHVlX3JhbmdlIHNvIHByZWV4aXN0aW5n IHJhbmdlIGluZm8gaXMKCW1lZGdlZCB3aXRoIG5ldyByYW5nZSBpbmZvLCBl dmVuIGlmIHRoZSBuZXcgcmFuZ2UgaXMgVlJfVkFSWUlORy4KCmRpZmYgLS1n aXQgYS9nY2MvZ2ltcGxlLXNzYS1ldnJwLWFuYWx5emUuYyBiL2djYy9naW1w bGUtc3NhLWV2cnAtYW5hbHl6ZS5jCmluZGV4IDU1MWIxZDYuLmZiM2QzMjkg MTAwNjQ0Ci0tLSBhL2djYy9naW1wbGUtc3NhLWV2cnAtYW5hbHl6ZS5jCisr KyBiL2djYy9naW1wbGUtc3NhLWV2cnAtYW5hbHl6ZS5jCkBAIC0yNzEsOCAr MjcxLDcgQEAgZXZycF9yYW5nZV9hbmFseXplcjo6cmVjb3JkX3Jhbmdlc19m cm9tX3N0bXQgKGdpbXBsZSAqc3RtdCkKICAgICAgIGVkZ2UgdGFrZW5fZWRn ZTsKICAgICAgIHZhbHVlX3JhbmdlIHZyID0gVlJfSU5JVElBTElaRVI7CiAg ICAgICB2cl92YWx1ZXMtPmV4dHJhY3RfcmFuZ2VfZnJvbV9zdG10IChzdG10 LCAmdGFrZW5fZWRnZSwgJm91dHB1dCwgJnZyKTsKLSAgICAgIGlmIChvdXRw dXQKLQkgICYmICh2ci50eXBlID09IFZSX1JBTkdFIHx8IHZyLnR5cGUgPT0g VlJfQU5USV9SQU5HRSkpCisgICAgICBpZiAob3V0cHV0KQogCXsKIAkgIHZy X3ZhbHVlcy0+dXBkYXRlX3ZhbHVlX3JhbmdlIChvdXRwdXQsICZ2cik7CiAK --------------04151DEF5DE3748028D234C2--