From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5386 invoked by alias); 5 Dec 2012 20:22:18 -0000 Received: (qmail 5370 invoked by uid 22791); 5 Dec 2012 20:22:16 -0000 X-SWARE-Spam-Status: No, hits=-7.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail4-relais-sop.national.inria.fr (HELO mail4-relais-sop.national.inria.fr) (192.134.164.105) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Dec 2012 20:22:08 +0000 Received: from ip-53.net-81-220-141.rev.numericable.fr (HELO laptop-mg.local) ([81.220.141.53]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 05 Dec 2012 21:22:04 +0100 Date: Wed, 05 Dec 2012 20:22:00 -0000 From: Marc Glisse To: Paolo Bonzini cc: ebotcazou@adacore.com, gcc-patches@gcc.gnu.org, Uros Bizjak , "H.J. Lu" Subject: Re: [i386] scalar ops that preserve the high part of a vector In-Reply-To: <50BF7F36.7010101@gnu.org> Message-ID: References: <50BF7F36.7010101@gnu.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; 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-12/txt/msg00349.txt.bz2 On Wed, 5 Dec 2012, Paolo Bonzini wrote: > Il 05/12/2012 15:22, Marc Glisse ha scritto: >> + >> + /* The x86 back-end uses VEC_CONCAT to set an element in a V2DF, but >> + VEC_MERGE for scalar operations that preserve the other elements >> + of a vector. */ >> + if (GET_CODE (trueop1) == VEC_SELECT >> + && GET_MODE (XEXP (trueop1, 0)) == mode >> + && XVECLEN (XEXP (trueop1, 1), 0) == 1 >> + && INTVAL (XVECEXP (XEXP (trueop1, 1), 0, 0)) == 1) >> + { >> + rtx newop0 = gen_rtx_fmt_e (VEC_DUPLICATE, mode, trueop0); >> + rtx newop1 = XEXP (trueop1, 0); >> + return gen_rtx_fmt_eee (VEC_MERGE, mode, newop0, newop1, >> + const1_rtx); >> + } > > So this changes this: > > (vec_concat:M R1:N (vec_select:N V2:M [1])) > > to this > > (vec_merge:M (vec_duplicate:M R1:N) V2:M [1]) Yes. > I wonder if more patterns in i386.md should be canonicalized. > Basically, the occurrences of gen_rtx_VEC_CONCAT should be changed to > simplify_gen_binary, and the fallout fixed. > > Otherwise you have patterns that will not match if someone does generate > the vec_concat via simplify_gen_binary. I wondered about that but underestimated the issue. If we decide that the vec_merge pattern is the canonical one, we should probably start by making ix86_expand_vector_set and others generate it (instead of the vec_concat one), and the simplify-rtx patch actually becomes less useful (but not useless). I don't know Uros' position, but re-reading this message: http://gcc.gnu.org/ml/gcc-patches/2012-12/msg00069.html it seems like he was indeed suggesting this. Note that my first choice was to have the vec_concat pattern in sse.md (I like the vec_concat pattern better, and since ix86_expand_vector_set has a special case to generate it instead of vec_merge for V2DF, someone must have agreed at some point), but Uros wants a single entry (using macros) for V4SF+V2DF, and hence a similar pattern. The only simplification we currently have with VEC_MERGE is constant propagation. If we are going to produce it more often, we need to add a few optimizations, like looking through a vec_select of a vec_merge, or doing nothing when merging a vector with itself, etc. -- Marc Glisse