From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1447 invoked by alias); 6 Nov 2013 16:02:32 -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 1437 invoked by uid 89); 6 Nov 2013 16:02:32 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.2 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RDNS_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no version=3.3.2 X-HELO: mail-bk0-f42.google.com Received: from Unknown (HELO mail-bk0-f42.google.com) (209.85.214.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Wed, 06 Nov 2013 16:02:30 +0000 Received: by mail-bk0-f42.google.com with SMTP id w16so1803372bkz.1 for ; Wed, 06 Nov 2013 08:02:21 -0800 (PST) X-Received: by 10.204.2.140 with SMTP id 12mr24426bkj.47.1383753741477; Wed, 06 Nov 2013 08:02:21 -0800 (PST) Received: from localhost ([2.28.235.51]) by mx.google.com with ESMTPSA id b7sm23831010bkg.1.2013.11.06.08.02.20 for (version=TLSv1.2 cipher=AES128-GCM-SHA256 bits=128/128); Wed, 06 Nov 2013 08:02:20 -0800 (PST) From: Richard Sandiford To: Tejas Belagod Mail-Followup-To: Tejas Belagod ,"gcc-patches\@gcc.gnu.org" , rdsandiford@googlemail.com Cc: "gcc-patches\@gcc.gnu.org" Subject: Re: [Patch, RTL] Eliminate redundant vec_select moves. References: <527A4309.70209@arm.com> <8738n9sj8o.fsf@talisman.default> <527A5EF4.5090505@arm.com> Date: Wed, 06 Nov 2013 16:14:00 -0000 In-Reply-To: <527A5EF4.5090505@arm.com> (Tejas Belagod's message of "Wed, 06 Nov 2013 15:23:32 +0000") Message-ID: <87y551r01p.fsf@talisman.default> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-11/txt/msg00594.txt.bz2 Tejas Belagod writes: > Richard Sandiford wrote: >> Tejas Belagod writes: >>> + /* This is big-endian-safe because the elements are kept in target >>> + memory order. So, for eg. PARALLEL element value of 2 is the same in >>> + either endian-ness. */ >>> + if (GET_CODE (src) == VEC_SELECT >>> + && REG_P (XEXP (src, 0)) && REG_P (dst) >>> + && REGNO (XEXP (src, 0)) == REGNO (dst)) >>> + { >>> + rtx par = XEXP (src, 1); >>> + int i; >>> + >>> + for (i = 0; i < XVECLEN (par, 0); i++) >>> + { >>> + rtx tem = XVECEXP (par, 0, i); >>> + if (!CONST_INT_P (tem) || INTVAL (tem) != i) >>> + return 0; >>> + } >>> + return 1; >>> + } >>> + >> >> I think for big endian it needs to be: >> >> INTVAL (tem) != i + base >> >> where base is something like: >> >> int base = GET_MODE_NUNITS (GET_MODE (XEXP (src, 0))) - XVECLEN (par, 0); >> >> E.g. a big-endian V4HI looks like: >> >> msb lsb >> 0000111122223333 >> >> and shortening it to say V2HI only gives the low 32 bits: >> >> msb lsb >> 22223333 > > But, in this case we want > > msb lsb > 00001111 It depends on whether the result occupies a full register or not. I was thinking of the case where it didn't, but I realise now you were thinking of the case where it did. And yeah, my suggestion doesn't cope with that... > I was under the impression that the const vector parallel for vec_select > represents the element indexes of the array in memory order. > > Therefore, in bigendian, > > msb lsb > 0000 1111 2222 3333 > element a[0] a[1] a[2] a[3] > > and in littleendian > > msb lsb > 3333 2222 1111 0000 > element a[3] a[2] a[1] a[0] Right. But if an N-bit value is stored in a register, it's assumed to occupy the lsb of the register and the N-1 bits above that. The other bits in the register are don't-care. E.g., leaving vectors to one side, if you have: (set (reg:HI N) (truncate:SI (reg:SI N))) on a 32-bit !TRULY_NOOP_TRUNCATION target, it shortens like this: msb lsb 01234567 VVVV xxxx4567 rather than: msb lsb 01234567 VVVV 0123xxxx for both endiannesses. The same principle applies to vectors. The lsb of the register is always assumed to be significant. So maybe the original patch was correct for partial-register and full-register results on little-endian, but only for full-register results on big-endian. Thanks, Richard