From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23783 invoked by alias); 14 Jan 2015 07:35:53 -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 23748 invoked by uid 89); 14 Jan 2015 07:35:51 -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_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-User: qpsmtpd, 2 recipients X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 14 Jan 2015 07:35:50 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t0E7ZiO2007861 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 14 Jan 2015 02:35:45 -0500 Received: from [10.3.113.77] (ovpn-113-77.phx2.redhat.com [10.3.113.77]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t0E7ZiKW003732; Wed, 14 Jan 2015 02:35:44 -0500 Message-ID: <54B61C4F.9070103@redhat.com> Date: Wed, 14 Jan 2015 08:37:00 -0000 From: Jeff Law User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: Eric Botcazou , gcc-patches@gcc.gnu.org CC: Richard Sandiford , Richard Sandiford , Alan Hayward , "steven@gcc.gnu.org" Subject: Re: [PATCH][rtlanal.c][BE][1/2] Fix vector load/stores to not use ld1/st1 References: <2243996.KNkFcg5eZm@polaris> <87a91qg50x.fsf@googlemail.com> <13670880.MKCSlOSr3D@polaris> In-Reply-To: <13670880.MKCSlOSr3D@polaris> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-01/txt/msg00980.txt.bz2 On 01/13/15 11:55, Eric Botcazou wrote: > >> (1) we have a non-paradoxical subreg; >> (2) both (reg:ymode xregno) and (reg:xmode xregno) occupy full >> hard registers (no padding or unused upper bits); >> (3) (reg:ymode xregno) and (reg:xmode xregno) store the same number >> of bytes (X) in each constituent hard register; >> (4) the offset is a multiple of X, i.e. the data we're accessing >> is aligned to a register boundary; and >> (5) endianness is regular (no differences between words and bytes, >> or between registers and memory) > > OK, that's a nice translation of the new code. :-) > > It seems to me that the patch wants to extend the support of generic subregs > to modes whose sizes are not multiple of each other, which is a requirement of > the existing code, but does that in a very specific case for the sake of the > ARM port without saying where all the above restrictions come from. Basically we're lifting the restriction that the the sizes are multiples of each other. The requirements above are the set where we know it will work. They are target independent, but happen to match what the ARM needs. The certainly do short circuit the meat of the function, that's the whole point, there's this set of conditions under which we know this will work and when they hold, we bypass. Now one could argue that instead of bypassing we should put the code to handle this situation further down. I'd be leery of doing that just from a complexity standpoint. But one could also argue that short circuiting like the patch does adds complexity as well and may be a bit kludgy. Maybe the way forward here is for someone to try and integrate this support in the main part of the code and see how it looks. Then we can pick one. The downside is since this probably isn't a regression that work would need to happen quickly to make it into gcc-5. Which leads to another option, get the release managers to sign off on the kludge after gcc-5 branches and only install the kludge on the gcc-5 branch and insisting the other solution go in for gcc-6 and beyond. Not sure if they'd do that, but it's a discussion that could happen. jeff