From patchwork Wed Oct 28 09:43:49 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Richard Sandiford X-Patchwork-Id: 1389190 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=pass (p=none dis=none) header.from=gcc.gnu.org Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=XLhCup83; dkim-atps=neutral Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 4CLkDH6fSfz9sVW for ; Wed, 28 Oct 2020 20:43:57 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id B26DC385802D; Wed, 28 Oct 2020 09:43:55 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B26DC385802D DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1603878235; bh=hj4zxHNTs0WhjBUQif1zgB+UIGJQbp5oQdI8MYkv1eU=; h=To:Subject:Date:List-Id:List-Unsubscribe:List-Archive:List-Post: List-Help:List-Subscribe:From:Reply-To:From; b=XLhCup83N/jMeTcuW3FEIkHDyTZv7Dm2geBkPZz2lbWaAAFAeZ7L52eqiAi4EasQk gm2XbbHTdS1W+THPOsjWjjY8Z3Ff7KgYYAke0c8CMxucwzDrx0JGv24ruPDvmR3UAT gEi0vPHzE2U6vfvMTTyNaAFA2xfBXNKXxqd1neC4= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 418BB385801A for ; Wed, 28 Oct 2020 09:43:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 418BB385801A Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C3D7A16F8 for ; Wed, 28 Oct 2020 02:43:51 -0700 (PDT) Received: from localhost (e121540-lin.manchester.arm.com [10.32.98.126]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 6CEBE3F719 for ; Wed, 28 Oct 2020 02:43:51 -0700 (PDT) To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, richard.sandiford@arm.com Subject: [PATCH] value-range: Give up on POLY_INT_CST ranges [PR97457] Date: Wed, 28 Oct 2020 09:43:49 +0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 X-Spam-Status: No, score=-12.8 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Richard Sandiford via Gcc-patches From: Richard Sandiford Reply-To: Richard Sandiford Errors-To: gcc-patches-bounces@gcc.gnu.org Sender: "Gcc-patches" This PR shows another problem with calculating value ranges for POLY_INT_CSTs. We have: ivtmp_76 = ASSERT_EXPR POLY_INT_CST [9, 4294967294]> where the VQ coefficient is unsigned but is effectively acting as a negative number. We wrongly give the POLY_INT_CST the range: [9, INT_MAX] and things go downhill from there: later iterations of the unrolled epilogue are wrongly removed as dead. I guess this is the final nail in the coffin for doing VRP on POLY_INT_CSTs. For other similarly exotic testcases we could have overflow for any coefficient, not just those that could be treated as contextually negative. Testing TYPE_OVERFLOW_UNDEFINED doesn't seem like an option because we couldn't handle warn_strict_overflow properly. At this stage we're just recording a range that might or might not lead to strict-overflow assumptions later. It still feels like we should be able to do something here, but for now removing the code seems safest. It's also telling that there are no testsuite failures on SVE from doing this. Tested on aarch64-linux-gnu (with and without SVE) and x86_64-linux-gnu. OK for trunk and backports? Richard gcc/ PR tree-optimization/97457 * value-range.cc (irange::set): Don't decay POLY_INT_CST ranges to integer ranges. gcc/testsuite/ PR tree-optimization/97457 * gcc.dg/vect/pr97457.c: New test. --- gcc/testsuite/gcc.dg/vect/pr97457.c | 15 +++++++++++++++ gcc/value-range.cc | 30 +++++------------------------ 2 files changed, 20 insertions(+), 25 deletions(-) create mode 100644 gcc/testsuite/gcc.dg/vect/pr97457.c diff --git a/gcc/testsuite/gcc.dg/vect/pr97457.c b/gcc/testsuite/gcc.dg/vect/pr97457.c new file mode 100644 index 00000000000..506ba249b00 --- /dev/null +++ b/gcc/testsuite/gcc.dg/vect/pr97457.c @@ -0,0 +1,15 @@ +/* { dg-additional-options "-O3" } */ + +int a; +long c; +signed char d(char e, char f) { return e + f; } +int main(void) { + for (; a <= 1; a++) { + c = -8; + for (; c != 3; c = d(c, 1)) + ; + } + char b = c; + if (b != 3) + __builtin_abort(); +} diff --git a/gcc/value-range.cc b/gcc/value-range.cc index 7847104050c..2319c13388a 100644 --- a/gcc/value-range.cc +++ b/gcc/value-range.cc @@ -248,31 +248,11 @@ irange::set (tree min, tree max, value_range_kind kind) set_undefined (); return; } - if (kind == VR_RANGE) - { - /* Convert POLY_INT_CST bounds into worst-case INTEGER_CST bounds. */ - if (POLY_INT_CST_P (min)) - { - tree type_min = vrp_val_min (TREE_TYPE (min)); - widest_int lb - = constant_lower_bound_with_limit (wi::to_poly_widest (min), - wi::to_widest (type_min)); - min = wide_int_to_tree (TREE_TYPE (min), lb); - } - if (POLY_INT_CST_P (max)) - { - tree type_max = vrp_val_max (TREE_TYPE (max)); - widest_int ub - = constant_upper_bound_with_limit (wi::to_poly_widest (max), - wi::to_widest (type_max)); - max = wide_int_to_tree (TREE_TYPE (max), ub); - } - } - else if (kind != VR_VARYING) - { - if (POLY_INT_CST_P (min) || POLY_INT_CST_P (max)) - kind = VR_VARYING; - } + + if (kind != VR_VARYING + && (POLY_INT_CST_P (min) || POLY_INT_CST_P (max))) + kind = VR_VARYING; + if (kind == VR_VARYING) { set_varying (TREE_TYPE (min));