From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13067 invoked by alias); 19 Feb 2013 22:27:15 -0000 Received: (qmail 13048 invoked by uid 22791); 19 Feb 2013 22:27:14 -0000 X-SWARE-Spam-Status: No, hits=-4.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_MG,TW_SW X-Spam-Check-By: sourceware.org Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 19 Feb 2013 22:27:08 +0000 Received: from svr-orw-fem-01.mgc.mentorg.com ([147.34.98.93]) by relay1.mentorg.com with esmtp id 1U7veV-00035v-SM from Maciej_Rozycki@mentor.com ; Tue, 19 Feb 2013 14:27:07 -0800 Received: from SVR-IES-FEM-01.mgc.mentorg.com ([137.202.0.104]) by svr-orw-fem-01.mgc.mentorg.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 19 Feb 2013 14:27:07 -0800 Received: from [172.30.64.249] (137.202.0.76) by SVR-IES-FEM-01.mgc.mentorg.com (137.202.0.104) with Microsoft SMTP Server id 14.1.289.1; Tue, 19 Feb 2013 22:27:05 +0000 Date: Tue, 19 Feb 2013 22:27:00 -0000 From: "Maciej W. Rozycki" To: Richard Sandiford CC: "Moore, Catherine" , "gcc-patches@gcc.gnu.org" Subject: Re: FW: [PATCH] [MIPS] microMIPS gcc support In-Reply-To: <87sj4sw48r.fsf@talisman.default> Message-ID: References: <87y5mfjm4c.fsf@talisman.home> <87622noebh.fsf@talisman.default> <87ip5wv3rj.fsf@talisman.default> <87sj4sw48r.fsf@talisman.default> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" 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 X-SW-Source: 2013-02/txt/msg00921.txt.bz2 On Tue, 19 Feb 2013, Richard Sandiford wrote: > > Index: gcc.target/mips/umips-lwp-swp-2.c > > =================================================================== > > --- gcc.target/mips/umips-lwp-swp-2.c (revision 0) > > +++ gcc.target/mips/umips-lwp-swp-2.c (revision 0) > > @@ -0,0 +1,19 @@ > > +/* { dg-options "-mgp32 (-mmicromips)" } */ > > +/* { dg-skip-if "code quality test" { *-*-* } { "-O0" "-O1" "-Os" } { "" } } */ > > +int a[2]; > > + > > +MICROMIPS f (b) > > +{ > > + unsigned int i; > > + int *p; > > + for (p = &a[b], i = b; --i < ~0; ) > > + *--p = i * 3 + (int)a; > > + > > +} > > + > > +MICROMIPS main () > > +{ > > + a[0] = a[1] = 0; > > + f (2); > > +} > > +/* { dg-final { scan-assembler "\tswp\t\\\$3,0\\(\\\$3\\)" } }*/ > > Is this a test of the swap_p case? Thanks if so, but could you add a > comment saying where the SWP gets generated, and why the test needs > to be skipped at -O1 and -Os? TBH, it is -Os where size really matters, so IMHO it is the -Os optimisation level where LWP/SWP should be used where possible in the first place, even if it hurts performance for some reason (and where e.g. -O2 might decide to go for individual accesses instead). Not to be meant as a show-stopper for this initial implementation, but if the optimisation does not work for LWP/SWP at -Os for some reason, then I think there's something going seriously wrong somewhere (instruction lengths set wrong for example?) which looks to me worth investigating and acting upon accordingly as the next step. I saw cases with instruction lengths set too high with our trunk just about yesterday and MIPS16 code, e.g.: .file 1 "foo.c" .section .mdebug.abi32 .previous .gnu_attribute 4, 1 .abicalls .option pic0 .text .align 2 .globl foo .set mips16 .ent foo .type foo, @function foo: .frame $sp,32,$31 # vars= 0, regs= 1/0, args= 16, gp= 8 .mask 0x80000000,-4 .fmask 0x00000000,0 save 32,$31 # 11 *mips16e_save_restore [length = 4] .set noreorder .set nomacro jal bar # 22 call_split/2 [length = 8] li $4,0 # 5 *movsi_mips16/4 [length = 4] .set macro .set reorder restore 32,$31 # 18 *mips16e_save_restore [length = 4] j $31 # 20 simple_return_internal [length = 2] .end foo .size foo, .-foo -- it looks all wrong to me except for the final J. Of course I realise where it originally comes from, but I think it would be good if the initial pessimistic estimates were actually adjusted as more is known about actual insns produced. I wonder if we may have similar issues with microMIPS instruction size calculation triggering here. Maciej