From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28969 invoked by alias); 3 Dec 2012 15:34:57 -0000 Received: (qmail 28753 invoked by uid 22791); 3 Dec 2012 15:34:56 -0000 X-SWARE-Spam-Status: No, hits=-7.8 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_HI,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; Mon, 03 Dec 2012 15:34:49 +0000 Received: from stedding.saclay.inria.fr ([193.55.250.194]) by mail4-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES128-SHA; 03 Dec 2012 16:34:47 +0100 Received: from glisse (helo=localhost) by stedding.saclay.inria.fr with local-esmtp (Exim 4.80) (envelope-from ) id 1TfY2h-0002Q6-5I; Mon, 03 Dec 2012 16:34:47 +0100 Date: Mon, 03 Dec 2012 15:34:00 -0000 From: Marc Glisse To: Uros Bizjak cc: gcc-patches@gcc.gnu.org, "H.J. Lu" 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-12/txt/msg00124.txt.bz2 On Mon, 3 Dec 2012, Uros Bizjak wrote: > On Sun, Dec 2, 2012 at 1:30 PM, Marc Glisse wrote: > >>>> here is a patch. If it is accepted, I'll extend it to other vm patterns >>>> (mul, div, min, max are likely candidates, but I need to check the doc). >>>> It >>>> passed bootstrap+testsuite on x86_64-linux. >>>> >>>> >>>> 2012-12-01 Marc Glisse >>>> >>>> PR target/54855 >>>> gcc/ >>>> * config/i386/sse.md (_vm3): Rewrite >>>> pattern. >>>> * config/i386/i386-builtin-types.def: New function types. >>>> * config/i386/i386.c (ix86_expand_args_builtin): Likewise. >>>> (bdesc_args) <__builtin_ia32_addss, __builtin_ia32_subss, >>>> __builtin_ia32_addsd, __builtin_ia32_subsd>: Change prototype. >>>> * config/i386/xmmintrin.h: Adapt to new builtin prototype. >>>> * config/i386/emmintrin.h: Likewise. >>>> * doc/extend.texi (X86 Built-in Functions): Document changed >>>> prototype. >>>> >>>> testsuite/ >>>> * gcc.target/i386/pr54855-1.c: New testcase. >>>> * gcc.target/i386/pr54855-2.c: New testcase. >>> >>> >>> Yes, the approach looks correct to me, but I wonder why we have >>> different representations for v4sf and v2df cases? I'd say that we >>> should canonicalize patterns somewhere in the middle end (probably to >>> vec_merge variant, as IMO vec_dup looks like degenerated vec_merge >>> variant), otherwise we will have pattern explosion. >> >> >> (I assume s/vec_dup/vec_concat/ above) > > Ah, yes. > > 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. But I don't mind, if that's the version you prefer, I'll update the patch. Thanks, -- Marc Glisse