From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4652 invoked by alias); 14 Jan 2014 20:35: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 4638 invoked by uid 89); 14 Jan 2014 20:35:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-pd0-f182.google.com Received: from mail-pd0-f182.google.com (HELO mail-pd0-f182.google.com) (209.85.192.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 14 Jan 2014 20:35:28 +0000 Received: by mail-pd0-f182.google.com with SMTP id v10so129325pde.27 for ; Tue, 14 Jan 2014 12:35:26 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.66.132.69 with SMTP id os5mr4054944pab.114.1389731726299; Tue, 14 Jan 2014 12:35:26 -0800 (PST) Received: by 10.70.92.72 with HTTP; Tue, 14 Jan 2014 12:35:26 -0800 (PST) In-Reply-To: <1389656268.18332.33.camel@gnopaine> References: <1389656268.18332.33.camel@gnopaine> Date: Tue, 14 Jan 2014 20:35:00 -0000 Message-ID: Subject: Re: [PATCH,rs6000] Implement -maltivec=be for vec_mule and vec_mulo Altivec intrinsics From: David Edelsohn To: Bill Schmidt Cc: GCC Patches Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2014-01/txt/msg00833.txt.bz2 On Mon, Jan 13, 2014 at 6:37 PM, Bill Schmidt wrote: > This patch provides for interpreting parity of element numbers for the > Altivec vec_mule and vec_mulo intrinsics as big-endian (left to right in > a vector register) when targeting a little endian machine and specifying > -maltivec=be. New test cases are added to test this functionality on > all supported vector types. > > The main change is in the altivec.md define_insns for > vec_widen_{su}mult_{even,odd}_{v8hi,v16qi}, where we now test for > VECTOR_ELT_ORDER_BIG rather than BYTES_BIG_ENDIAN in order to treat the > element order as big-endian. However, this necessitates changes to > other places in altivec.md where we previously called > gen_vec_widen_{su}mult_*. The semantics of these internal uses are not > affected by -maltivec=be, so these are now replaced with direct > generation of the underlying instructions that were previously > generated. > > Bootstrapped and tested with no new regressions on > powerpc64{,le}-unknown-linux-gnu. Ok for trunk? > > Thanks, > Bill > > > gcc: > > 2014-01-13 Bill Schmidt > > * config/rs6000/altivec.md (mulv8hi3): Explicitly generate vmulesh > and vmulosh rather than call gen_vec_widen_smult_*. > (vec_widen_umult_even_v16qi): Test VECTOR_ELT_ORDER_BIG rather > than BYTES_BIG_ENDIAN to determine use of even or odd instruction. > (vec_widen_smult_even_v16qi): Likewise. > (vec_widen_umult_even_v8hi): Likewise. > (vec_widen_smult_even_v8hi): Likewise. > (vec_widen_umult_odd_v16qi): Likewise. > (vec_widen_smult_odd_v16qi): Likewise. > (vec_widen_umult_odd_v8hi): Likewise. > (vec_widen_smult_odd_v8hi): Likewise. > (vec_widen_umult_hi_v16qi): Explicitly generate vmuleub and > vmuloub rather than call gen_vec_widen_umult_*. > (vec_widen_umult_lo_v16qi): Likewise. > (vec_widen_smult_hi_v16qi): Explicitly generate vmulesb and > vmulosb rather than call gen_vec_widen_smult_*. > (vec_widen_smult_lo_v16qi): Likewise. > (vec_widen_umult_hi_v8hi): Explicitly generate vmuleuh and vmulouh > rather than call gen_vec_widen_umult_*. > (vec_widen_umult_lo_v8hi): Likewise. > (vec_widen_smult_hi_v8hi): Explicitly gnerate vmulesh and vmulosh > rather than call gen_vec_widen_smult_*. > (vec_widen_smult_lo_v8hi): Likewise. > > gcc/testsuite: > > 2014-01-13 Bill Schmidt > > * gcc.dg/vmx/mult-even-odd.c: New. > * gcc.dg/vmx/mult-even-odd-be-order.c: New. Okay. The less said the better. Thanks, David