From patchwork Tue Sep 8 00:00:35 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kugan Vivekanandarajah X-Patchwork-Id: 515256 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id E4FC61401F0 for ; Tue, 8 Sep 2015 10:00:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b=ngyxuMj5; dkim-atps=neutral DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; q=dns; s= default; b=fPFhX/63nt2blSoBExWJA1tbrMuegNq+LaCs3CtQA7qaP2AEfXWom mLYJpo2pZ/et7YCVVqlTzjSyQO9npHIYxuzMdPurI8tXg9RlNtCpyt4lXLU2Wp4Q 0+glIvzlzUv6GnYzwIaGsAktG/Ioj/fJq/sRDYbHPe2Qe5gjbFQmik= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender :subject:to:references:cc:from:message-id:date:mime-version :in-reply-to:content-type:content-transfer-encoding; s=default; bh=ObBmEGROLQthysN1dvVStx7L+Ps=; b=ngyxuMj5R2WxR3qrkCWIlG5mMRgR Wp8fYqB65FCZPWvMvkhe90TuOP97QIVuawPAZZNOGX72suMTvJO3IoVl4h/VUAyK LmecpEnLn8LaCKlDdqgr1Sykk6Za7uvv64yqdOPPXYry2M2ud5/HJGF8/+uJBLd3 h1aP9li2FIiVBI4= Received: (qmail 54126 invoked by alias); 8 Sep 2015 00:00:47 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 54115 invoked by uid 89); 8 Sep 2015 00:00:47 -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 X-HELO: mail-pa0-f51.google.com Received: from mail-pa0-f51.google.com (HELO mail-pa0-f51.google.com) (209.85.220.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 08 Sep 2015 00:00:45 +0000 Received: by padhy16 with SMTP id hy16so104856547pad.1 for ; Mon, 07 Sep 2015 17:00:44 -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-type :content-transfer-encoding; bh=6TUcfkiFrKEYIZ6a3XWF/aEZ9b/VOU0nYs71aX6o3HY=; b=LWSL8YEPdCwqXuC5FooKYFmJ5MgP0Ycjj4ZDjUdvHW8MidXp6UdW0pKdekgJyW5EiL fji0udF0ROPMu3vMwya3R8/a3Tuxbt6Qy/pT/HVrYU4TQ/FMB2xc26dBe+DualVme0rD 74Cp+OzPEzy0MWL6eLxHwGXPeQRl6R2T/g5Qwt+84C2FIPaiAE0DqwndFAT8pyqx4Wif CbCLUVo+cvGNLm996aXmrXAv8nUQIemeNnXQH8Db2JpKCQa62AU12JkdzFHEN6hl7ljU czC4BiF6Nj6TEQjEEytmW4wLwqNFNaMkr+o3LurHNF2vCTWkAa5U/1xdbxdWnzwnFCJZ awSA== X-Gm-Message-State: ALoCoQnIj5KYOVaDkktWsqSF3MQL0XLYrQcbkVWW5inzdLzc9eHtHKmo604nOJ5xl4iApsRGRUIa X-Received: by 10.68.69.98 with SMTP id d2mr50429686pbu.137.1441670443812; Mon, 07 Sep 2015 17:00:43 -0700 (PDT) Received: from [10.1.1.7] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by smtp.googlemail.com with ESMTPSA id f11sm1025357pdl.73.2015.09.07.17.00.41 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 07 Sep 2015 17:00:43 -0700 (PDT) Subject: Re: [5/7] Allow gimple debug stmt in widen mode To: Michael Matz References: <55ECFC2A.7050908@linaro.org> <55ECFE08.8060405@linaro.org> Cc: "gcc-patches@gcc.gnu.org" , Richard Biener From: Kugan Message-ID: <55EE2523.6000209@linaro.org> Date: Tue, 8 Sep 2015 10:00:35 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: X-IsSubscribed: yes Thanks for the review. On 07/09/15 23:20, Michael Matz wrote: > Hi, > > On Mon, 7 Sep 2015, Kugan wrote: > >> Allow GIMPLE_DEBUG with values in promoted register. > > Patch does much more. > Oops sorry. Copy and paste mistake. gcc/ChangeLog: 2015-09-07 Kugan Vivekanandarajah * cfgexpand.c (expand_debug_locations): Remove assert as now we are also allowing values in promoted register. * gimple-ssa-type-promote.c (fixup_uses): Allow GIMPLE_DEBUG to bind values in promoted register. * rtl.h (wi::int_traits ::decompose): Accept zero extended value also. >> gcc/ChangeLog: >> >> 2015-09-07 Kugan Vivekanandarajah >> >> * expr.c (expand_expr_real_1): Set proper SUNREG_PROMOTED_MODE for >> SSA_NAME that was set by GIMPLE_CALL and assigned to another >> SSA_NAME of same type. > > ChangeLog doesn't match patch, and patch contains dubious changes: > >> --- a/gcc/cfgexpand.c >> +++ b/gcc/cfgexpand.c >> @@ -5240,7 +5240,6 @@ expand_debug_locations (void) >> tree value = (tree)INSN_VAR_LOCATION_LOC (insn); >> rtx val; >> rtx_insn *prev_insn, *insn2; >> - machine_mode mode; >> >> if (value == NULL_TREE) >> val = NULL_RTX; >> @@ -5275,16 +5274,6 @@ expand_debug_locations (void) >> >> if (!val) >> val = gen_rtx_UNKNOWN_VAR_LOC (); >> - else >> - { >> - mode = GET_MODE (INSN_VAR_LOCATION (insn)); >> - >> - gcc_assert (mode == GET_MODE (val) >> - || (GET_MODE (val) == VOIDmode >> - && (CONST_SCALAR_INT_P (val) >> - || GET_CODE (val) == CONST_FIXED >> - || GET_CODE (val) == LABEL_REF))); >> - } >> >> INSN_VAR_LOCATION_LOC (insn) = val; >> prev_insn = PREV_INSN (insn); > > So it seems that the modes of the values location and the value itself > don't have to match anymore, which seems dubious when considering how a > debugger should load the value in question from the given location. So, > how is it supposed to work? For example (simplified test-case from creduce): fn1() { char a = fn1; return a; } Please see that DEBUG now points to _2 which is a promoted mode. I am assuming that the debugger would load required precision from promoted register. May be I am missing the details but how else we can handle this? Any suggestions? In this particular simplified case, we do have _6 but we might not in all the case. > > And this change: > >> --- a/gcc/rtl.h >> +++ b/gcc/rtl.h >> @@ -2100,6 +2100,8 @@ wi::int_traits ::decompose (HOST_WIDE_INT*, >> targets is 1 rather than -1. */ >> gcc_checking_assert (INTVAL (x.first) >> == sext_hwi (INTVAL (x.first), precision) >> + || INTVAL (x.first) >> + == (INTVAL (x.first) & ((1 << precision) - 1)) >> || (x.second == BImode && INTVAL (x.first) == 1)); >> >> return wi::storage_ref (&INTVAL (x.first), 1, precision); > > implies that wide_ints are not always sign-extended anymore after you > changes. That's a fundamental assumption, so removing that assert implies > that you somehow created non-canonical wide_ints, and those will cause > bugs elsewhere in the code. Don't just remove asserts, they are usually > there for a reason, and without accompanying changes those reasons don't > go away. > This comes from GIMPLE_DEBUG. If this assumption should always hold, I will fix it there. Thanks, Kugan --- test.c.142t.veclower21 2015-09-07 23:47:26.362201640 +0000 +++ test.c.143t.promotion 2015-09-07 23:47:26.362201640 +0000 @@ -5,13 +5,18 @@ { char a; long int fn1.0_1; + unsigned int _2; int _3; + unsigned int _5; + char _6; : fn1.0_1 = (long int) fn1; - a_2 = (char) fn1.0_1; - # DEBUG a => a_2 - _3 = (int) a_2; + _5 = (unsigned int) fn1.0_1; + _2 = _5 & 255; + # DEBUG a => _2 + _6 = (char) _2; + _3 = (int) _6; return _3; }