From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31132 invoked by alias); 3 Nov 2012 11:10:51 -0000 Received: (qmail 31118 invoked by uid 22791); 3 Nov 2012 11:10:49 -0000 X-SWARE-Spam-Status: No, hits=-3.6 required=5.0 tests=AWL,BAYES_00,DKIM_ADSP_CUSTOM_MED,DKIM_SIGNED,DKIM_VALID,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_SPAMHAUS_DROP,NML_ADSP_CUSTOM_MED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,TW_XT X-Spam-Check-By: sourceware.org Received: from mail-wi0-f179.google.com (HELO mail-wi0-f179.google.com) (209.85.212.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 03 Nov 2012 11:10:44 +0000 Received: by mail-wi0-f179.google.com with SMTP id hq7so1526641wib.8 for ; Sat, 03 Nov 2012 04:10:43 -0700 (PDT) Received: by 10.216.193.158 with SMTP id k30mr1578545wen.89.1351941041847; Sat, 03 Nov 2012 04:10:41 -0700 (PDT) Received: from localhost ([2.26.192.222]) by mx.google.com with ESMTPS id fa9sm1969468wib.5.2012.11.03.04.10.40 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 03 Nov 2012 04:10:41 -0700 (PDT) From: Richard Sandiford To: gcc-patches@gcc.gnu.org Mail-Followup-To: gcc-patches@gcc.gnu.org, rdsandiford@googlemail.com Subject: [0/8] Add optabs alternatives for insv, extv and extzv Date: Sat, 03 Nov 2012 11:10:00 -0000 Message-ID: <87k3u3eybu.fsf@talisman.home> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.3 (gnu/linux) 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: 2012-11/txt/msg00253.txt.bz2 This series was inspired by Andrew's patch from September: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00126.html and by a general frustration with the insv, extv and extzv interface. The patches add 6 new optabs: insvM: an M<-M register insertion insvmisalignM: a BLK<-M memory insertion extvM: a signed M<-M register extraction extvmisalignM: a signed M<-BLK memory extraction extzvM: an unsigned M<-M register extraction extzvmisalignM: an unsigned M<-BLK memory extraction The BLKmode memory references are to the full bitfield, instead of just a byte_mode memory reference to the first byte. I used "misalign" to emphasise that there's no alignment guarantee for the memory operand. I've tried to leave open the possibility of having (aligned) M<-M memory operations in future, but I haven't added them here because I have no use case. It's also not clear to me whether we'd want to generate the memory form during expand or leave it up to combine. The main target of this change is MIPS64r2, which can do both 32-bit and 64-bit insertions and extractions. The current rtl code tends to do things in 64 bits, because that's how the insv and ext(z)v interface is defined, but doing things in 64 bits requires any 32-bit results to be explicitly "truncated" (i.e. sign-extended). Providing the optabs interface makes both widths available. Tested on x86_64-linux-gnu, powerpc64-linux-gnu and mipsisa64-elf. Also tested by making sure that there were no changes in assembly output for a set of gcc .ii files. On the other hand, the -march=octeon output for a set of mips64-linux-gnu gcc .ii files showed the optimisation kicking in as hoped. Richard