From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30332 invoked by alias); 3 Aug 2018 07:58:31 -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 30321 invoked by uid 89); 3 Aug 2018 07:58:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=0.6 required=5.0 tests=BAYES_00,BODY_8BITS,GARBLED_BODY,GIT_PATCH_2,HTML_MESSAGE,KAM_LAZY_DOMAIN_SECURITY,MIME_CHARSET_FARAWAY,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 spammy=8:06, 8:=c8=d5, 8:18, 8:20?= X-HELO: smtp2200-217.mail.aliyun.com Received: from smtp2200-217.mail.aliyun.com (HELO smtp2200-217.mail.aliyun.com) (121.197.200.217) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 03 Aug 2018 07:58:27 +0000 X-Alimail-AntiSpam:AC=CONTINUE;BC=0.07444417|-1;CH=green;FP=0|0|0|0|0|-1|-1|-1;HT=e02c03302;MF=yunhai_shang@c-sky.com;NM=1;PH=DS;RN=4;RT=4;SR=0;TI=SMTPD_---.CZ5E7K5_1533283094; Received: from 172.16.32.77(mailfrom:yunhai_shang@c-sky.com fp:SMTPD_---.CZ5E7K5_1533283094) by smtp.aliyun-inc.com(10.147.41.120); Fri, 03 Aug 2018 15:58:14 +0800 From: Yunhai Message-Id: <42A133FD-E6BC-4E83-8026-3790EC764963@c-sky.com> Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\)) Subject: Re: [2/5] C-SKY port: Backend implementation Date: Fri, 03 Aug 2018 07:58:00 -0000 In-Reply-To: <1632a78d-4244-fe7b-91ae-ffdd1dd8cf60@redhat.com> Cc: =?gb2312?B?9sTPye21?= , Sandra Loosemore , "gcc-patches@gcc.gnu.org" To: Jeff Law References: <49d0a2c8-51a0-4a74-d015-0bf1c1098e38@codesourcery.com> <28cb3a6e-4594-3545-5236-c68784af6a57@codesourcery.com> <8a1b9bac-82dc-bb4f-e0a2-9a9b9cbea98a@redhat.com> <56004587-F43E-4004-B618-B819CF7A5E4A@c-sky.com> <1632a78d-4244-fe7b-91ae-ffdd1dd8cf60@redhat.com> Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-08/txt/msg00263.txt.bz2 > =D4=DA 2018=C4=EA8=D4=C23=C8=D5=A3=AC06:27=A3=ACJeff Law = =D0=B4=B5=C0=A3=BA >=20 > On 07/26/2018 12:06 AM, =F6=C4=CF=C9=ED=B5 wrote: >>=20 >>> =D4=DA 2018=C4=EA7=D4=C225=C8=D5=A3=AC=C9=CF=CE=E75:24=A3=ACJeff Law =D0=B4=B5=C0=A3=BA >>>=20 >>> On 07/24/2018 12:18 PM, Sandra Loosemore wrote: >>>> On 07/24/2018 09:45 AM, Jeff Law wrote: >>>>> On 07/23/2018 10:21 PM, Sandra Loosemore wrote: >>>>> I'm not a big fan of more awk code, but I'm not going to object to it= :-) >>>>>=20 >>>>> Why does the port have its own little pass for condition code >>>>> optimization (cse_cc)? What is it doing that can't be done with our >>>>> generic optimizers? >>>>=20 >>>> This pass was included in the initial patch set we got from C-SKY, and >>>> as it didn't seem to break anything I left it in. Perhaps C-SKY can >>>> provide a testcase that demonstrates why it's still useful in the >>>> current version of GCC; otherwise we can remove this from the initial >>>> port submission and restore it later if some performance analysis shows >>>> it is still worthwhile. >>> FWIW it looks like we model CC setting on just a few insns, (add, >>> subtract) so I'd be surprised if this little mini pass found much. I'd >>> definitely like to hear from the csky authors here. >>>=20 >>> Alternately, you could do add some instrumentation to flag when it >>> triggers, take a test or two that does, reduce it and we can then look >>> at the key RTL sequences and see what the pass is really doing. >>>=20 >>=20 >> I wrote a case to reproduce this problem on C-SKY. C code is as follows: >> ----------------------------------------------------------------------- >> int e1, e2; >>=20 >> void func (int a, int b, int c, int d, int f, int g) >> { >> e1 =3D a > b ? f : g; >> e2 =3D a > b ? c : d; >>=20 >> return; >> } >> ----------------------------------------------------------------------- >>=20 >> compile to assembler with option =A1=B0-O3 -S=A1=B1 : >> ----------------------------------------------------------------------- >> func: >> cmplt a1, a0 >> ld.w t1, (sp, 0) >> ld.w t0, (sp, 4) >> movt t0, t1 >> cmplt a1, a0 >> movt a3, a2 >> lrw a1, e2 >> lrw a2, e1 >> st.w a3, (a1, 0) >> st.w t0, (a2, 0) >> rts >> ----------------------------------------------------------------------- >> There is an extra =A1=B0cmplt a1, a0" in the above code without cse_cc. = This situation mainly occurs when a relatively short branch jump is convert= ed into a conditional execution instruction. And the CSE pass can not reduc= e the same conditional comparison instruction . Here is the rtx sequence af= ter =A1=B0cse2=A1=B1 pass. >>=20 >> ----------------------------------------------------------------------- >> (insn 28 13 29 2 (set (reg:CC 33 c) >> (gt:CC (reg/v:SI 77 [ a ]) >> (reg/v:SI 78 [ b ]))) func.c:5 1099 {*cmpgtsi} >> (nil)) >> (insn 29 28 30 2 (set (reg/v:SI 82 [ g ]) >> (if_then_else:SI (eq (reg:CC 33 c) >> (const_int 0 [0])) >> (reg/v:SI 82 [ g ]) >> (reg/v:SI 81 [ f ]))) func.c:5 983 {movf} >> (expr_list:REG_DEAD (reg/v:SI 81 [ f ]) >> (expr_list:REG_DEAD (reg:CC 33 c) >> (nil)))) >> (insn 30 29 31 2 (set (reg:CC 33 c) >> (gt:CC (reg/v:SI 77 [ a ]) >> (reg/v:SI 78 [ b ]))) func.c:5 1099 {*cmpgtsi} >> (expr_list:REG_DEAD (reg/v:SI 78 [ b ]) >> (expr_list:REG_DEAD (reg/v:SI 77 [ a ]) >> (nil)))) >> (insn 31 30 18 2 (set (reg/v:SI 80 [ d ]) >> (if_then_else:SI (eq (reg:CC 33 c) >> (const_int 0 [0])) >> (reg/v:SI 80 [ d ]) >> (reg/v:SI 79 [ c ]))) func.c:5 983 {movf} >> (expr_list:REG_DEAD (reg/v:SI 79 [ c ]) >> (expr_list:REG_DEAD (reg:CC 33 c) >> (nil)))) >> ----------------------------------------------------------------------- >>=20 >> It doesn't seem to check the same conditional comparison instruction .So= I wrote this to solve this problem, but I am not sure if this is the best = way : ) >>=20 >> PS, the same conditional comparison instruction cannot be reduced with t= he latest version gcc with C-SKY because I just insert the =A1=B0cse_cc=A1= =B1 after =A1=B0cse1=A1=B1, when I insert after =A1=B0cse2=A1=B1, this prob= lem can be solved very well. > I think the cse_cc pass is really just working around one or more bugs > in CSE and/or a backend bug. The RTL above clearly shows a common > subexpression that is not eliminated by CSE. >=20 > What CSE should be trying to do is changing the second and third > occurrences of (gt:CC (reg 77) (reg 78)) with (reg 33) which would > create nop-sets which would be subsequently deleted. I suspect you do > not have an insn which matches that nop set of the CC register. If you > fix that I suspect CSE will work better and eliminate the need for your > cse_cc pass. Thanks you for your suggestions, we will try this method. >=20 > jeff