From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24578 invoked by alias); 14 Oct 2012 11:42:22 -0000 Received: (qmail 24570 invoked by uid 22791); 14 Oct 2012 11:42:21 -0000 X-SWARE-Spam-Status: No, hits=-7.0 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,RCVD_IN_NJABL_PROXY,RP_MATCHES_RCVD,TW_ZJ 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; Sun, 14 Oct 2012 11:42:17 +0000 Received: from ip-158.net-81-220-131.standre.rev.numericable.fr (HELO laptop-mg.local) ([81.220.131.158]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 14 Oct 2012 13:42:15 +0200 Date: Sun, 14 Oct 2012 12:52:00 -0000 From: Marc Glisse To: Uros Bizjak cc: gcc-patches@gcc.gnu.org Subject: Re: [i386] scalar ops that preserve the high part of a vector In-Reply-To: Message-ID: References: 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-10/txt/msg01334.txt.bz2 On Sun, 14 Oct 2012, Uros Bizjak wrote: > On Sat, Oct 13, 2012 at 10:52 AM, Marc Glisse wrote: >> Hello, >> >> this patch provides an alternate pattern to let combine recognize scalar >> operations that preserve the high part of a vector. If the strategy is all >> right, I could do the same for more operations (mul, div, ...). Something >> similar is also possible for V4SF (different pattern though), but probably >> not as useful. > > But, we _do_ have vec_merge pattern that describes the operation. > Adding another one to each operation just to satisfy combine is IMO > not correct approach. At some point I wondered about _replacing_ the existing pattern, so there would only be one ;-) The vec_merge pattern takes as argument 2 vectors instead of a vector and a scalar, and describes the operation as a vector operation where we drop half of the result, instead of a scalar operation where we re-add the top half of the vector. I don't know if that's the most convenient choice. Adding code in simplify-rtx to replace vec_merge with vec_concat / vec_select might be easier than the other way around. If the middle-end somehow gave us: (plus X (vec_concat Y 0)) it would seem a bit strange to add an optimization that turns it into: (vec_merge (plus X (subreg:V2DF Y)) X 1) but then producing: (vec_concat (plus (vec_select X 0) Y) (vec_select X 1)) would be strange as well. (ignoring the signed zero issues here) > I'd rather see generic RTX simplification that > simplifies your proposed pattern to vec_merge pattern. Ok, I'll see what I can do. > Also, as you mention in PR54855, Comment #5, the approach is too > fragile... I am not sure I can make the RTX simplification much less fragile... Whenever I see (vec_concat X (vec_select Y 1)), I would have to check whether X is some (possibly large) tree of scalar computations involving Y[0], move it all to vec_merge computations, and fix other users of some of those scalars to now use S[0]. Seems too hard, I would stop at single-operation X that is used only once. Besides, the gain is larger in proportion when there is a single operation :-) Thank you for your comments, -- Marc Glisse