From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92185 invoked by alias); 19 Jun 2015 02:37:55 -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 92172 invoked by uid 89); 19 Jun 2015 02:37:54 -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-pd0-f171.google.com Received: from mail-pd0-f171.google.com (HELO mail-pd0-f171.google.com) (209.85.192.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 19 Jun 2015 02:37:52 +0000 Received: by pdbci14 with SMTP id ci14so21246391pdb.2 for ; Thu, 18 Jun 2015 19:37:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=lmK+igBX8uZX6FEjD1rgLZ8AVlJnID3mUn91/U/hvWA=; b=ldHekESr6UQ7r5v0O4ghcj1zIZ8ZdSdKwHFDV/j/SUQGE0kQspmGtmsBfpt08VUNEp X2203lSw/aCuhXAAyB2XxWm9QG/qOoZ0bOhCFN6Qtqtaph/Z5HmZ672V/afT5ux7i4UJ PJajKHufiM4Pfp2O7SqxT2WBXe0AMIxjT8AdifLg5WpOBJpvgqgLDC9qM/oax+6DLY2K jljsB5MYnnlJCYWp+EuxWiOapQcmYJ2yhYRJwuLcoVUQV5BrVtHFHf0n2eQKa/W98mSw ocFZ5m6kua17IdbM/0+HO1PIFTS1ctLO7EU/hjPD5qKPo610B+FtDtM62EY4/grmXzTi R/CA== X-Gm-Message-State: ALoCoQms9JyJSw9twzmRIZkSN70gKVTtC4UDUn1Xn8qEVjM2NhzaOFa/UlKLULQfyLuuCcYhwKeK X-Received: by 10.70.109.199 with SMTP id hu7mr27158510pdb.71.1434681470706; Thu, 18 Jun 2015 19:37:50 -0700 (PDT) Received: from [10.1.1.6] (58-6-183-210.dyn.iinet.net.au. [58.6.183.210]) by mx.google.com with ESMTPSA id yn5sm9490541pac.48.2015.06.18.19.37.47 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 18 Jun 2015 19:37:49 -0700 (PDT) Message-ID: <55838078.3070900@linaro.org> Date: Fri, 19 Jun 2015 02:55:00 -0000 From: Kugan User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Richard Biener CC: Jeff Law , "gcc-patches@gcc.gnu.org" , Jakub Jelinek Subject: Re: [RFC] Elimination of zext/sext - type promotion pass References: <53FEDF34.4090605@linaro.org> <5407DF57.2040902@linaro.org> <540912E1.30505@linaro.org> <545FF8EE.1090900@linaro.org> <554303F0.1000103@linaro.org> <556CE742.4090507@linaro.org> In-Reply-To: <556CE742.4090507@linaro.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-06/txt/msg01313.txt.bz2 ping? Thanks, Kugan On 02/06/15 09:14, Kugan wrote: > > > On 08/05/15 22:48, Richard Biener wrote: >> You compute which promotions are unsafe, like sources/sinks of memory >> (I think you miss call arguments/return values and also asm operands here). >> But instead of simply marking those SSA names as not to be promoted >> I'd instead split their life-ranges, thus replace >> >> _1 = mem; >> >> with >> >> _2 = mem; >> _1 = [zs]ext (_2, ...); >> >> and promote _1 anyway. So in the first phase I'd do that (and obviously >> note that _2 isn't to be promoted in the specific example). >> >> For promotions that apply I wouldn't bother allocating new SSA names >> but just "fix" their types (assign to their TREE_TYPE). This also means >> they have to become anonymous and if they didn't have a !DECL_IGNORED_P >> decl before then a debug stmt should be inserted at the point of the >> promotions. So >> >> bar_3 = _1 + _2; >> >> when promoted would become >> >> _4 = _1 + _2; >> _3 = sext <_4, ...>; >> # DEBUG bar = (orig-type) _4; // or _3? >> >> so you'd basically always promote defs (you have a lot of stmt/operand >> walking code I didn't look too closely at - but it looks like too much) and >> the uses get promoted automagically (because you promote the original >> SSA name). Promotion of constants has to remain, of course. > > > Thanks Richard. I experimented on this idea to understand it better. > Please see the attached prototype (I am still working on your other > comments which is not addressed here). Please have a look and let me > know if this is along what you would expect. I have few questions though. > > 1. In the following example above : > char _1; > _1 = mem; > > when changing with > > char _2; > int _1; > _2 = mem; > _1 = [zs]ext (_2, ...); > > for the [zs]ext operation we now use BIT_AND_EXPR and ZEXT_EXPR which > (as of now) requires that the LHS and RHS are of the same type. Are you > suggesting that we should have a true ZEXT_EXPR and SEXT_EXPR which can > do the above in the gimple? I am now using CONVER_EXPR and which is the > source of many optimization issue. > > 2. for inline asm (a reduced test case that might not make much as a > stand alone test-case, but I ran into similar cases with valid programmes) > > ;; Function fn1 (fn1, funcdef_no=0, decl_uid=4220, cgraph_uid=0, > symbol_order=0) > > fn1 (short int p1) > { > : > __asm__("" : "=r" p1_2 : "0" p1_1(D)); > return; > > } > > > I am generating something like the following which ICEs. What is the > expected out? > > ;; Function fn1 (fn1, funcdef_no=0, decl_uid=4220, cgraph_uid=0, > symbol_order=0) > > fn1 (short int p1) > { > int _1; > int _2; > short int _5; > > : > _1 = (int) p1_4(D); > _5 = (short int) _1; > __asm__("" : "=r" p1_6 : "0" _5); > _2 = (int) p1_6; > return; > > } > > Thanks a lot for your time, > Kugan >