From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15839 invoked by alias); 7 Dec 2012 15:06:00 -0000 Received: (qmail 15825 invoked by uid 22791); 7 Dec 2012 15:05:59 -0000 X-SWARE-Spam-Status: No, hits=-6.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 07 Dec 2012 15:05:48 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB7F5lAN014002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Dec 2012 10:05:47 -0500 Received: from pebble.twiddle.home (vpn-10-241.rdu.redhat.com [10.11.10.241]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id qB7F5hwJ024879; Fri, 7 Dec 2012 10:05:44 -0500 Message-ID: <50C205C8.2060906@redhat.com> Date: Fri, 07 Dec 2012 15:06:00 -0000 From: Richard Henderson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: Marc Glisse CC: Michael Zolotukhin , Kirill Yukhin , "H.J. Lu" , Uros Bizjak , gcc-patches List Subject: Re: [i386] scalar ops that preserve the high part of a vector References: <50C20079.8050001@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-12/txt/msg00502.txt.bz2 On 2012-12-07 09:00, Marc Glisse wrote: > On Fri, 7 Dec 2012, Richard Henderson wrote: > >> On 2012-12-07 02:49, Marc Glisse wrote: >>> For 2-element vectors, vec_concat does seem more natural than >>> vec_merge. If we chose vec_merge as the canonical representation, we >>> should chose it for setting an element in a vector >>> (ix86_expand_vector_set) everywhere, not just those scalarish >>> operations. >> >> I'd hate to enshrine vec_merge over vec_concat for the benefit of x86, >> and to the detriment of e.g. mips. There are plenty of embedded simd >> implementations that are V2xx only. >> >> If we simply pull the various x86 patterns into one common form, set >> and extract included, does that buy us most of what we'd get for >> playing games in combine? > > I'm sorry, could you be more precise? I don't see clearly what you are suggesting. Don't change combine? Have I lost the plot somewhere here? r~