From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14540 invoked by alias); 21 Jan 2015 17:53:29 -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 14510 invoked by uid 89); 21 Jan 2015 17:53:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,SPF_PASS autolearn=ham version=3.3.2 X-HELO: service87.mimecast.com Received: from service87.mimecast.com (HELO service87.mimecast.com) (91.220.42.44) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Jan 2015 17:53:24 +0000 Received: from cam-owa2.Emea.Arm.com (fw-tnat.cambridge.arm.com [217.140.96.140]) by service87.mimecast.com; Wed, 21 Jan 2015 17:53:21 +0000 Received: from localhost ([10.1.255.212]) by cam-owa2.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 21 Jan 2015 17:53:19 +0000 From: Richard Sandiford To: Eric Botcazou Mail-Followup-To: Eric Botcazou ,gcc-patches@gcc.gnu.org, Marcus Shawcroft , Jeff Law , Alan Hayward , "steven\@gcc.gnu.org" , richard.sandiford@arm.com Cc: gcc-patches@gcc.gnu.org, Marcus Shawcroft , Jeff Law , Alan Hayward , "steven\@gcc.gnu.org" Subject: Re: [PATCH][rtlanal.c][BE][1/2] Fix vector load/stores to not use ld1/st1 In-Reply-To: <1695077.g5BBHXBRRL@polaris> (Eric Botcazou's message of "Tue, 20 Jan 2015 23:50:11 +0100") References: <8761c1f939.fsf@googlemail.com> <1695077.g5BBHXBRRL@polaris> User-Agent: Gnus/5.130012 (Ma Gnus v0.12) Emacs/24.3 (gnu/linux) Date: Wed, 21 Jan 2015 18:03:00 -0000 Message-ID: <873874rpf4.fsf@e105548-lin.cambridge.arm.com> MIME-Version: 1.0 X-MC-Unique: 115012117532100201 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2015-01/txt/msg01931.txt.bz2 Eric Botcazou writes: >> Seems like the thread might have died down, so just wanted to ping it. >> As Marcus says, this is holding up other patches so it'd be good to get >> something in soon. Would it be OK to commit the original patch or should >> we wait? > > Yes, go ahead, but add a FIXME or ??? comment. Thanks, here's what I installed. Richard gcc/ 2015-01-25 Alan Hayward * rtlanal.c (subreg_get_info): Exit early for simple and common cases. Index: gcc/rtlanal.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- gcc/rtlanal.c 2015-01-21 17:06:33.594664514 +0000 +++ gcc/rtlanal.c 2015-01-21 17:10:22.863830284 +0000 @@ -3440,6 +3440,22 @@ subreg_get_info (unsigned int xregno, ma info->offset =3D offset / regsize_xmode; return; } + /* Quick exit for the simple and common case of extracting whole + subregisters from a multiregister value. */ + /* ??? It would be better to integrate this into the code below, + if we can generalize the concept enough and figure out how + odd-sized modes can coexist with the other weird cases we support. */ + if (!rknown + && WORDS_BIG_ENDIAN =3D=3D REG_WORDS_BIG_ENDIAN + && regsize_xmode =3D=3D regsize_ymode + && (offset % regsize_ymode) =3D=3D 0) + { + info->representable_p =3D true; + info->nregs =3D nregs_ymode; + info->offset =3D offset / regsize_ymode; + gcc_assert (info->offset + info->nregs <=3D nregs_xmode); + return; + } } =20 /* Lowpart subregs are otherwise valid. */