From patchwork Wed Nov 10 17:18:58 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: "H.J. Lu" X-Patchwork-Id: 70653 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id 09240B70F1 for ; Thu, 11 Nov 2010 04:19:15 +1100 (EST) Received: (qmail 8710 invoked by alias); 10 Nov 2010 17:19:06 -0000 Received: (qmail 8693 invoked by uid 22791); 10 Nov 2010 17:19:04 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mail-pz0-f47.google.com (HELO mail-pz0-f47.google.com) (209.85.210.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 10 Nov 2010 17:18:59 +0000 Received: by pzk34 with SMTP id 34so199301pzk.20 for ; Wed, 10 Nov 2010 09:18:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.142.178.10 with SMTP id a10mr7290764wff.391.1289409538125; Wed, 10 Nov 2010 09:18:58 -0800 (PST) Received: by 10.220.118.12 with HTTP; Wed, 10 Nov 2010 09:18:58 -0800 (PST) In-Reply-To: <20101110152857.GC2722@kam.mff.cuni.cz> References: <20101110150951.GA6604@kam.mff.cuni.cz> <20101110151821.GB6604@kam.mff.cuni.cz> <20101110152857.GC2722@kam.mff.cuni.cz> Date: Wed, 10 Nov 2010 09:18:58 -0800 Message-ID: Subject: Re: Revision 166517 caused PR 46414 From: "H.J. Lu" To: Jan Hubicka Cc: GCC Patches X-IsSubscribed: yes Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org 2010/11/10 Jan Hubicka : >> On Wed, Nov 10, 2010 at 7:18 AM, Jan Hubicka wrote: >> >> The complette unrilling seems sane here. >> >> This seems like good idea to me and i am not quite sure why 32bit compilation does not do the >> >> transofrm. I will check now. >> > >> > The reason is word size.  We compute move costs based on this, so vectorized moves are more expensive >> > in 32bit cost model than 64bit. >> > Perhaps there is way to hook vectorizer cost model in here? >> > >> >> Shouldn't we use vector size to compute move cost for vector move? > > That would work for me.  I am not terribly familiar with vector costs here, could you try to patch > estimate_move_cost in tree-inline.c? > We are very simplistic here assuming that pretty much all operations have cost of 1, so I guess > making all vector moves to have cost 1 is fine. The main reason for that function is to catch large > structure copies. > How about this patch? diff --git a/gcc/testsuite/gcc.target/i386/recip-vec-sqrtf-avx.c b/gcc/testsuite/gcc.target/i386/recip-vec-sqrtf-avx.c index 506df88..5a8e696 100644 --- a/gcc/testsuite/gcc.target/i386/recip-vec-sqrtf-avx.c +++ b/gcc/testsuite/gcc.target/i386/recip-vec-sqrtf-avx.c @@ -32,4 +32,4 @@ void t3(void) } /* Last loop is small enough to be fully unrolled. */ -/* { dg-final { scan-assembler-times "vrsqrtps\[ \\t\]+\[^\n\]*%ymm" 4 } } */ +/* { dg-final { scan-assembler-times "vrsqrtps\[ \\t\]+\[^\n\]*%ymm" 6 } } */ diff --git a/gcc/tree-inline.c b/gcc/tree-inline.c index fc470a7..f900a0e 100644 --- a/gcc/tree-inline.c +++ b/gcc/tree-inline.c @@ -3249,6 +3249,14 @@ estimate_move_cost (tree type) gcc_assert (!VOID_TYPE_P (type)); + if (TREE_CODE (type) == VECTOR_TYPE) + { + enum machine_mode inner = TYPE_MODE (TREE_TYPE (type)); + enum machine_mode simd + = targetm.vectorize.preferred_simd_mode (inner); + return GET_MODE_SIZE (TYPE_MODE (type)) / GET_MODE_SIZE (simd); + } + size = int_size_in_bytes (type); if (size < 0 || size > MOVE_MAX_PIECES * MOVE_RATIO (!optimize_size))