From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2317 invoked by alias); 7 Dec 2012 14:43:16 -0000 Received: (qmail 2309 invoked by uid 22791); 7 Dec 2012 14:43:16 -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 14:43:11 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id qB7EhAjs007604 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 7 Dec 2012 09:43:10 -0500 Received: from pebble.twiddle.home (vpn-10-241.rdu.redhat.com [10.11.10.241]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id qB7Eh58a031703; Fri, 7 Dec 2012 09:43:07 -0500 Message-ID: <50C20079.8050001@redhat.com> Date: Fri, 07 Dec 2012 14:43: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: 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/msg00497.txt.bz2 On 2012-12-07 02:49, Marc Glisse wrote: > The root problem is that we model the subs[sd] instructions as taking > a 128-bit second operand, when Intel's documentation says they take a > 32/64-bit operand, which is an important difference for memory > operands (and constants). Writing a pattern that reconstructs the > result from a scalar operation also seems more natural than > pretending we are doing a parallel operation and dropping most of it > (easier for recog and friends). I agree this is a problem with the current representation. > 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? As for your xmmintrin.h changes, I'd like to see a test case that verifies that _mm_add_ss(a, b) does not add extra insns to extract __B[0]. > +(define_insn "_vm3" > [(set (match_operand:VF_128 0 "register_operand" "=x,x") > (vec_merge:VF_128 > - (plusminus:VF_128 > - (match_operand:VF_128 1 "register_operand" "0,x") > - (match_operand:VF_128 2 "nonimmediate_operand" "xm,xm")) > + (vec_duplicate:VF_128 > + (plusminus: > + (vec_select: > + (match_operand:VF_128 1 "register_operand" "0,x") > + (parallel [(const_int 0)])) > + (match_operand: 2 "nonimmediate_operand" "xm,xm"))) > (match_dup 1) > (const_int 1)))] > "TARGET_SSE" > "@ > \t{%2, %0|%0, %2} > v\t{%2, %1, %0|%0, %1, %2}" > [(set_attr "isa" "noavx,avx") > (set_attr "type" "sseadd") > (set_attr "prefix" "orig,vex") > (set_attr "mode" "")]) Did this really trigger as a substitution? It's not supposed to have, since you didn't add (set_attr "replace_vec_merge_with_vec_concat" "yes")... r~