From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6612 invoked by alias); 9 Jan 2013 17:40:25 -0000 Received: (qmail 6531 invoked by uid 22791); 9 Jan 2013 17:40:21 -0000 X-SWARE-Spam-Status: No, hits=-4.9 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,TW_AV,TW_OV,TW_VD,TW_VS,TW_ZJ X-Spam-Check-By: sourceware.org Received: from mail-ob0-f171.google.com (HELO mail-ob0-f171.google.com) (209.85.214.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 09 Jan 2013 17:40:16 +0000 Received: by mail-ob0-f171.google.com with SMTP id dn14so2474751obc.30 for ; Wed, 09 Jan 2013 09:40:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.60.29.226 with SMTP id n2mr38294913oeh.132.1357753215788; Wed, 09 Jan 2013 09:40:15 -0800 (PST) Received: by 10.182.153.201 with HTTP; Wed, 9 Jan 2013 09:40:15 -0800 (PST) In-Reply-To: References: <20130108200057.GM7269@tucnak.redhat.com> Date: Wed, 09 Jan 2013 17:40:00 -0000 Message-ID: Subject: Re: [PATCH] Allow x <- x, 1 in *vec_concatv2df (PR rtl-optimization/55829) From: Uros Bizjak To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Vladimir Makarov 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: 2013-01/txt/msg00500.txt.bz2 On Wed, Jan 9, 2013 at 10:23 AM, Uros Bizjak wrote: >> No matter whether LRA (if it is a bug in there) is fixed or not, >> *vec_concatv2df could handle for !avx sse3 x <- x, 1 alternative the same >> as it handles x <- m, 1 alternative (using movddup). >> >> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? >> >> 2013-01-08 Jakub Jelinek >> >> PR rtl-optimization/55829 >> * config/i386/sse.md (*vec_concatv2df): Add x <- x, 1 alternative >> for sse3 but not avx. >> >> * gcc.target/i386/pr55829.c: New test. >> >> --- gcc/config/i386/sse.md.jj 2012-11-26 10:14:26.000000000 +0100 >> +++ gcc/config/i386/sse.md 2013-01-08 10:28:42.496819712 +0100 >> @@ -5183,10 +5183,10 @@ (define_insn "vec_dupv2df" >> (set_attr "mode" "V2DF")]) >> >> (define_insn "*vec_concatv2df" >> - [(set (match_operand:V2DF 0 "register_operand" "=x,x,x,x,x,x,x,x") >> + [(set (match_operand:V2DF 0 "register_operand" "=x,x,x, x,x,x,x,x") >> (vec_concat:V2DF >> - (match_operand:DF 1 "nonimmediate_operand" " 0,x,m,0,x,m,0,0") >> - (match_operand:DF 2 "vector_move_operand" " x,x,1,m,m,C,x,m")))] >> + (match_operand:DF 1 "nonimmediate_operand" " 0,x,xm,0,x,m,0,0") >> + (match_operand:DF 2 "vector_move_operand" " x,x,1, m,m,C,x,m")))] > > This was done on purpose, since reload had some problems with similar > pattern (please see PR 50875 [1] and [2]). If we are sure that LRA > fixes this problem, then the patch is OK for mainline. > > Also, please revert "hack" that fixed PR 50875 in this case. Looking into this problem a bit more: After Vladimir's LRA patch went in, we generate for gcc.target/i386/pr55829.c: movq p1(%rip), %r12 # 56 *movdi_internal_rex64/2 [length = 7] movq %r12, (%rsp) # 57 *movdi_internal_rex64/4 [length = 4] movddup (%rsp), %xmm1 # 23 *vec_concatv2df/3 [length = 5] Combined with your proposed patch: movq p1(%rip), %r12 # 60 *movdi_internal_rex64/2 [length = 7] movq %r12, (%rsp) # 61 *movdi_internal_rex64/4 [length = 4] movsd (%rsp), %xmm1 # 56 *movdf_internal_rex64/10 [length = 5] unpcklpd %xmm1, %xmm1 # 23 *vec_concatv2df/1 [length = 4] That is, one more move to use unpcklpd. Based on this evidence, I think that the proposed patch should be rejected, the generic LRA fix alone results in better code. Thanks, Uros.