From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-patches-return-333357-listarch-gcc-patches=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 10983 invoked by alias); 3 Dec 2012 08:53:54 -0000
Received: (qmail 10966 invoked by uid 22791); 3 Dec 2012 08:53:53 -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-da0-f47.google.com (HELO mail-da0-f47.google.com) (209.85.210.47)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 08:53:48 +0000
Received: by mail-da0-f47.google.com with SMTP id s35so1064772dak.20        for <gcc-patches@gcc.gnu.org>; Mon, 03 Dec 2012 00:53:48 -0800 (PST)
MIME-Version: 1.0
Received: by 10.68.197.71 with SMTP id is7mr27308090pbc.79.1354524828371; Mon, 03 Dec 2012 00:53:48 -0800 (PST)
Received: by 10.66.246.232 with HTTP; Mon, 3 Dec 2012 00:53:48 -0800 (PST)
In-Reply-To: <alpine.DEB.2.02.1212021215330.3747@laptop-mg.saclay.inria.fr>
References: <alpine.DEB.2.02.1210131032460.9651@stedding.saclay.inria.fr>	<CAFULd4YHdLF1ZyxrMG8MhRjo40f-EfAJZnDOEBc80pOGa4WNGQ@mail.gmail.com>	<alpine.DEB.2.02.1210141057010.3752@laptop-mg.saclay.inria.fr>	<alpine.DEB.2.02.1211301317160.3783@laptop-mg.saclay.inria.fr>	<CAFULd4bVFbr1KC6FrjWOhEfmqEr_v2VuQMFjg4+TpTB681=HhA@mail.gmail.com>	<alpine.DEB.2.02.1211302244290.3783@laptop-mg.saclay.inria.fr>	<alpine.DEB.2.02.1212011800400.19206@stedding.saclay.inria.fr>	<CAFULd4Z=8xeVScUM7JSqkHHXJrmO7qVa40q-h-mUE+Vehb86vw@mail.gmail.com>	<alpine.DEB.2.02.1212021215330.3747@laptop-mg.saclay.inria.fr>
Date: Mon, 03 Dec 2012 08:53:00 -0000
Message-ID: <CAFULd4Z4Ywk+BQupB+=tDKiWx5QrCt9VL83XF4Xtgu03=y0VZw@mail.gmail.com>
Subject: Re: [i386] scalar ops that preserve the high part of a vector
From: Uros Bizjak <ubizjak@gmail.com>
To: Marc Glisse <marc.glisse@inria.fr>
Cc: gcc-patches@gcc.gnu.org, "H.J. Lu" <hjl.tools@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-patches.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
List-Post: <mailto:gcc-patches@gcc.gnu.org>
List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
Sender: gcc-patches-owner@gcc.gnu.org
X-SW-Source: 2012-12/txt/msg00099.txt.bz2

On Sun, Dec 2, 2012 at 1:30 PM, Marc Glisse <marc.glisse@inria.fr> 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  <marc.glisse@inria.fr>
>>>
>>>         PR target/54855
>>> gcc/
>>>         * config/i386/sse.md (<sse>_vm<plusminus_insn><mode>3): 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.

Uros.