From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 33969 invoked by alias); 9 Aug 2016 21:51:35 -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 33858 invoked by uid 89); 9 Aug 2016 21:51:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1240, 2016-08-10, 20160810 X-HELO: mail-pf0-f180.google.com Received: from mail-pf0-f180.google.com (HELO mail-pf0-f180.google.com) (209.85.192.180) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 09 Aug 2016 21:51:24 +0000 Received: by mail-pf0-f180.google.com with SMTP id h186so8686031pfg.3 for ; Tue, 09 Aug 2016 14:51:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=CSJd88az8Mf1q2vRhKyXDGmmIfFCtuMdpkX2yfSERKA=; b=Iw1+kXoOQt+KKIEtvvD2a8BJdo8DSXL2kDlNzwfWrTawhETNdn0n99KFbjy+IOMoPI VVSYDqXV3oQJBLM92d03jeldPCYrcbI3+LTSuAqPR07Dl/nrNvIUrxvc2dHOWv77DarN N8ecjVlc20iIbS96ZlGJM6hqnNJsgV4e+7YgDoBhawXztlJrgRL5PxdpeD31SFiuDuao l37StKyNg9akuMoOUZjuEKTVukEtWcpTeLdarnh3RvXlHE8WSY9l5FiQItOrlFMTpi6S diNCTdBfb9ob3PuDkR/Aa5iqUQS0s9MH4X7LlKwiAjcXKGmr1a/BIEzN/ZI+vVUldo2v rXTw== X-Gm-Message-State: AEkoouuXlZgRIe8QVa6kJ2abbZW1RWxawpJZysBe01hySJZWqo7eJaYWl+xIpN82ShG8DfA8 X-Received: by 10.98.75.65 with SMTP id y62mr953625pfa.99.1470779482690; Tue, 09 Aug 2016 14:51:22 -0700 (PDT) Received: from [10.1.1.4] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.gmail.com with ESMTPSA id u1sm58255926pfu.12.2016.08.09.14.51.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 Aug 2016 14:51:21 -0700 (PDT) Subject: Re: [PR72835] Incorrect arithmetic optimization involving bitfield arguments To: Jakub Jelinek References: <0a1eaaf8-3ede-cd56-ffb5-40b25f94e46e@linaro.org> <98613cff-7c48-1a56-0014-6d87c35a8f26@linaro.org> <20160809214617.GB14857@tucnak.redhat.com> Cc: "gcc-patches@gcc.gnu.org" , Richard Biener From: kugan Message-ID: <7210cceb-be3b-44b1-13b7-4152e89d2a4f@linaro.org> Date: Tue, 09 Aug 2016 21:51:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160809214617.GB14857@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00763.txt.bz2 Hi Jakub, On 10/08/16 07:46, Jakub Jelinek wrote: > On Wed, Aug 10, 2016 at 07:42:25AM +1000, kugan wrote: >> There was no new regression while testing. I also moved the testcase from >> gcc.dg/torture/pr72835.c to gcc.dg/tree-ssa/pr72835.c. Is this OK for trunk? > > This looks strange. The tree-ssa-reassoc.c code has been trying to never > reuse SSA_NAMEs if they would hold a different value. > So there should be no resetting of flow sensitive info needed. We are not reusing but, if you see the example change in reassoc: - _5 = -_4; - _6 = _2 * _5; + _5 = _4; + _6 = _5 * _2; _5 and _6 will now have different value ranges because they compute different values. Therefore I think we should reset (?). Thanks, Kugan > >> gcc/testsuite/ChangeLog: >> >> 2016-08-10 Kugan Vivekanandarajah >> >> PR tree-optimization/72835 >> * gcc.dg/tree-ssa/pr72835.c: New test. >> >> gcc/ChangeLog: >> >> 2016-08-10 Kugan Vivekanandarajah >> >> PR tree-optimization/72835 >> * tree-ssa-reassoc.c (rewrite_expr_tree): Reset value_range of LHS when >> operands are changed. >> (rewrite_expr_tree_parallel): Likewise. > > Jakub >