From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5746 invoked by alias); 3 Dec 2012 17:55:12 -0000 Received: (qmail 5738 invoked by uid 22791); 3 Dec 2012 17:55:11 -0000 X-SWARE-Spam-Status: No, hits=-5.0 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-pb0-f47.google.com (HELO mail-pb0-f47.google.com) (209.85.160.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 17:55:03 +0000 Received: by mail-pb0-f47.google.com with SMTP id un1so1934487pbc.20 for ; Mon, 03 Dec 2012 09:55:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.237.1 with SMTP id uy1mr31062767pbc.145.1354557303098; Mon, 03 Dec 2012 09:55:03 -0800 (PST) Received: by 10.66.246.232 with HTTP; Mon, 3 Dec 2012 09:55:02 -0800 (PST) In-Reply-To: References: Date: Mon, 03 Dec 2012 17:55:00 -0000 Message-ID: Subject: Re: [i386] scalar ops that preserve the high part of a vector From: Uros Bizjak To: Marc Glisse Cc: gcc-patches@gcc.gnu.org, "H.J. Lu" Content-Type: text/plain; charset=ISO-8859-1 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/msg00138.txt.bz2 On Mon, Dec 3, 2012 at 4:34 PM, Marc Glisse wrote: >> However, looking a bit more into the usage cases for these patterns, >> they are only used through intrinsics with _m128 operands. While your >> proposed patch makes these patterns more general (they can use 64bit >> aligned memory), this is not their usual usage, and for their intended >> usage, your proposed improvement complicates these patterns >> unnecessarily. Following on these facts, I'd say that we leave these >> special patters (since they serve their purpose well) and rather >> introduce new patterns for "other" uses. > > > You mean like in the original patch? > http://gcc.gnu.org/ml/gcc-patches/2012-10/msg01279.html > > (it only had the V2DF version, not the V4SF one) > > Funny how we switched sides, now I am the one who would rather have a single > pattern instead of having one for the builtin and one for recog. It seems > that once we add the new pattern, keeping the old one is a waste of > maintenance time, and the few extra rtx from the slightly longer pattern for > these seldomly used builtins should be negligible. Yes, I didn't notice at the time that the intention of existing patterns was to implement intrinsics that exclusively use _m128 operands. > But I don't mind, if that's the version you prefer, I'll update the patch. Actually, both approaches have their benefits and drawbacks. Specialized vec_merge patterns can be efficiently macroized, and support builtins with _m128 operands in a simple and efficient way. You are proposing patterns that do not macroize well (this is what was learned from your last patch) and require breakup of existing macroized patterns. So, we are actually adding new functionality - operations on an array of values. IMO, this warrants new patterns, but please find a way for V2DF and V4SF to macroize in the same way. Uros.