From patchwork Mon Feb 11 15:43:18 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Christophe Lyon X-Patchwork-Id: 219623 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 CDEFC2C02A7 for ; Tue, 12 Feb 2013 02:43:42 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1361202223; h=Comment: DomainKey-Signature:Received:Received:Received:Received: MIME-Version:Received:In-Reply-To:References:Date:Message-ID: Subject:From:To:Cc:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=7wQd+qQl97wT4mwsJa5jfjXwlXQ=; b=gy8kPPfAtdLnuKQ ZDICuVAEiRzkA+4yHHAk2i1HPVAHFq/9DVegekybFersZn4PbGf4eFF3cTqzMV1+ D+T+f/52ZpYxrTgzvWH45FCOjQnvrZLM5/Gy64apTG0wT+yhbeTXZYCDNcHp+YC9 k15HB0j7hoSeZKjNIsKsqFKOggdo= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:X-Spam-Check-By:Received:Received:X-Google-DKIM-Signature:MIME-Version:X-Received:Received:In-Reply-To:References:Date:Message-ID:Subject:From:To:Cc:Content-Type:X-Gm-Message-State:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=h6c0NSZiiuf2I0X+T6Pu9DgtZZnLeIYAQMPZgPP3bftZYQgbNWftdCjRoR6tbn 4bk3GxE0nTi4AjnUvSXNjgr8m5WjyRRdygFp7lNim9RnnQW8RBxvVCxQ5pUIYnbB yfOkmuCO8ynbWsnjC7MaceuQhKcxEtGiuRzuK0z5nuES0=; Received: (qmail 17048 invoked by alias); 11 Feb 2013 15:43:29 -0000 Received: (qmail 16933 invoked by uid 22791); 11 Feb 2013 15:43:27 -0000 X-SWARE-Spam-Status: No, hits=-3.0 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, KHOP_THREADED, RCVD_IN_DNSWL_LOW, RCVD_IN_HOSTKARMA_YE X-Spam-Check-By: sourceware.org Received: from mail-oa0-f54.google.com (HELO mail-oa0-f54.google.com) (209.85.219.54) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Feb 2013 15:43:19 +0000 Received: by mail-oa0-f54.google.com with SMTP id n12so6401480oag.13 for ; Mon, 11 Feb 2013 07:43:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type:x-gm-message-state; bh=lfG6UIwGEinsl9DflEJJ0eSEqMpy0gL0CTfw2XmBfAU=; b=QH0AoGbuCIGXcFIGfZPpNHQj3zzTrLi41JXbXtyGcq7XO2kZD6NdqBp+5AYjrcEyRF 3BOBMJlfbSHFo054AjF0MpkO7Bf5cU5Eswpr/W3ElUdcCDEMPropS3PMC2kYXnoUrpdG mtQMsv+Q9TEp4rgTRaqCjHosTv8OHnUDepU/IdEo9oCxbcEHWXQBHA9U9CrWd7TdyM9Y k/BavJ3P1PG7mjJ7WOOV55JaQOmHo9NY1HEEPsRAeefKtosC+8WqQa3REXaUreZUai2D TOIzfm2sev0RioavOw1m3G9taVV4gBQZ+uFgMl2PPVtn/eEU0vATSGvKLHRjAVqUeKuq a6Fg== MIME-Version: 1.0 X-Received: by 10.60.7.129 with SMTP id j1mr10799200oea.54.1360597398745; Mon, 11 Feb 2013 07:43:18 -0800 (PST) Received: by 10.60.35.202 with HTTP; Mon, 11 Feb 2013 07:43:18 -0800 (PST) In-Reply-To: <5118CE98.4040802@arm.com> References: <5118CE98.4040802@arm.com> Date: Mon, 11 Feb 2013 16:43:18 +0100 Message-ID: Subject: Re: [PATCH][ARM] Implement vectorizer cost hooks From: Christophe Lyon To: Richard Earnshaw Cc: "gcc-patches@gcc.gnu.org" , Patch Tracking X-Gm-Message-State: ALoCoQkObZqeDiBGv9XvZc4xqSDDsw9PuPBBSDl6Z/ridTqJIdrNl2LOjyZPEZD8HNAZGFNd7phk 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 Richard, Thanks for your comments. Here a new version with the changes you suggested. Christophe On 11 February 2013 11:57, Richard Earnshaw wrote: > On 05/02/13 18:18, Christophe Lyon wrote: >> >> Hi, >> >> Following the discussion about "disable peeling" [1] a few weeks ago, >> it turned out that the vectorizer cost model needed some >> implementation for ARM. >> >> The attached patch implements arm_builtin_vectorization_cost and >> arm_add_stmt_cost, providing default costs when aligned and unaligned >> loads/stores have the same cost (=1). init_cost and finish_cost still >> use the default implementation (I noticed that x86 has chosen to >> duplicate the default implementation without changing it, why?) >> >> Benchmarking shows very little variation, expect a noticeable +1.6% on >> coremark. >> >> If this is OK, we can then discuss how to disable peeling completely >> when aligned and unaligned accesses have the same cost (and thus where >> peeling is a loss of performance). I think adding a new hook is >> necessary, since target descriptions may use different models for >> these costs (eg x86 makes no difference between unaligned loads and >> unaligned stores). >> >> Thanks, >> >> Christophe. >> >> [1] http://gcc.gnu.org/ml/gcc/2012-12/msg00036.html >> >> 2013-02-05 Christophe Lyon >> >> * config/arm/arm.c (arm_builtin_vectorization_cost) >> (arm_add_stmt_cost): New functions. >> (TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST) >> (TARGET_VECTORIZE_ADD_STMT_COST): Define. >> (struct processor_costs): New struct type. >> (default_arm_cost): New struct of type processor_costs.= >> > > Christophe, > > Thanks for the patch. This is mostly OK, but please can you make the > following changes. > > +struct processor_costs { > > Please name this something like cpu_vec_costs. It's not the only cost table > in the back-end. > > +struct processor_costs default_arm_cost = { /* arm generic costs. */ > > Similarly, use something like default_arm_vec_cost. > > +const struct processor_costs *arm_cost = &default_arm_cost; > > And here. But better still, link this through the current_tune table rather > than introducing a new global. > > Finally, > > @@ -27256,4 +27272,130 @@ arm_validize_comparison (rtx *comparison, rtx * > op1, rtx * op2) > > } > > +/* Vectorizer cost model implementation. */ > > > Please put the patch in a more suitable location rather than just dumping it > at the end of the file. There are already numerous functions related to > costs that are mostly grouped together. I suggest this goes near the > rtx_costs code. > > R. > > diff --git a/gcc/ChangeLog b/gcc/ChangeLog index bfb857d..56fde74 100644 --- a/gcc/ChangeLog +++ b/gcc/ChangeLog @@ -1,3 +1,17 @@ +2013-02-05 Christophe Lyon + + * config/arm/arm-protos.h (struct cpu_vec_costs): New struct type. + (struct tune_params): Add vec_costs field. + * config/arm/arm.c (arm_builtin_vectorization_cost) + (arm_add_stmt_cost): New functions. + (TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST) + (TARGET_VECTORIZE_ADD_STMT_COST): Define. + (arm_default_vec_cost): New struct of type cpu_vec_costs. + (arm_slowmul_tune, arm_fastmul_tune, arm_strongarm_tune) + (arm_xscale_tune, arm_9e_tune, arm_v6t2_tune, arm_cortex_tune) + (arm_cortex_a15_tune, arm_cortex_a5_tune, arm_cortex_a9_tune) + (arm_v6m_tune, arm_fa726te_tune): Define new vec_costs field. + 2013-02-04 Alexander Potapenko Jack Howarth Jakub Jelinek