From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5675 invoked by alias); 9 Jun 2017 07:32:36 -0000 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 Received: (qmail 130120 invoked by uid 89); 9 Jun 2017 07:30:04 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-lf0-f43.google.com Received: from mail-lf0-f43.google.com (HELO mail-lf0-f43.google.com) (209.85.215.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 09 Jun 2017 07:30:02 +0000 Received: by mail-lf0-f43.google.com with SMTP id o83so26414463lff.3 for ; Fri, 09 Jun 2017 00:30:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=FwSA2DGBYGN8wmyZE/zzgNIAdC3UqbfWUDOiDrqN5ZU=; b=p3bn7l+dp/J8t2p17rzugQwyEXtKk4Q/24f1KXMA/u4cxbdsY53afvq3WWxR+dzrLQ 8S2jTBCo/f/vZpYNz1Gvn9xakist5vJQJET5EOfzgVPMhizcrnYCvzfp9Z4+fVEX0rjL 2Sjh8y+JY4OntLqm1QcRmD70wdA50YZ88MXO8obW82WGIRYLtGkaX8IuwAcfXmZeF7wn JhojPI6S6W7UJw5ePx5XK6AqlOK4IYAg8JEVfwzBPQSbzyffqg9J0b0dPHzl0ZXPyoFU hlGrC2/EQEh+AItlvANgTgyxMQrvgAiyDH2Um7wAxXKzLRTCi/Z8+lo1cybNV6pLK8/D WzfQ== X-Gm-Message-State: AODbwcAGMRDv5DXAaQ+PSfgR00fglEcwdqgf4CmkAnouGwoyTS3DLJvm 6LdLSXLUjs9vtA4Z X-Received: by 10.25.169.213 with SMTP id s204mr12479374lfe.119.1496993404420; Fri, 09 Jun 2017 00:30:04 -0700 (PDT) Received: from [192.168.1.65] (ppp109-252-218-78.pppoe.spdop.ru. [109.252.218.78]) by smtp.gmail.com with ESMTPSA id y26sm76257lja.22.2017.06.09.00.30.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Jun 2017 00:30:03 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH 4/6] Port prefetch configuration from aarch32 to aarch64 From: Maxim Kuvyrkov In-Reply-To: Date: Fri, 09 Jun 2017 07:32:00 -0000 Cc: James Greenhalgh , Andrew Pinski , GCC Patches , Kyrylo Tkachov , Richard Guenther , nd@arm.com Content-Transfer-Encoding: quoted-printable Message-Id: <08E3480F-6D0C-4562-A004-1EBEE0B45BA1@linaro.org> References: <4E4A2CDC-89F0-4CA4-804D-9B4442236276@linaro.org> <20170608134754.GA4880@arm.com> To: "Richard Earnshaw (lists)" X-SW-Source: 2017-06/txt/msg00572.txt.bz2 > On Jun 8, 2017, at 6:13 PM, Richard Earnshaw (lists) wrote: >=20 > On 08/06/17 14:47, James Greenhalgh wrote: >> On Mon, Jan 30, 2017 at 08:35:00AM -0800, Andrew Pinski wrote: >>> On Mon, Jan 30, 2017 at 3:48 AM, Maxim Kuvyrkov >>> wrote: >>>> This patch port prefetch configuration from aarch32 backend to aarch64= . There is no code-generation change from this patch. >>>>=20 >>>> This patch also happens to address Kyrill's comment on Andrew's prefet= ching patch at https://gcc.gnu.org/ml/gcc-patches/2017-01/msg02133.html . >>>>=20 >>>> This patch also fixes a minor bug in aarch64_override_options_internal= (), which used "selected_cpu->tune" instead of "aarch64_tune_params". >>>=20 >>> I am not a fan of the macro at all. >>=20 >> I'm with Andrew for this. The precedent in the AArch64 port is for >> explicitly spelling this out, as we do with the branch costs, approx_mod= es, >> vector costs etc. >>=20 >> I'd rather we went that route than the macro you're using. I don't have >> any objections to the rest of your patch. >>=20 >> Thanks, >> James >>=20 >=20 > I disagree with having to write all these things out, but I do agree > that we should be self-consistent within the port. I'm re-writing the patch with approach that James suggested, and instead of= AARCH64_PREFETCH_NOT_BENEFICIAL there will be "&generic_prefetch_tune", so= not much copy-paste of parameters. >=20 > The purpose of introducing the macros in the ARM port was to avoid the > common problem of merging adding new parameters with adding new ports. > C initializers for these tables assign values sequentially with > zero-padding at the end, so failing to merge such changes carefully > leads to real bugs in the compiler (even if just performance bugs). >=20 > I notice that the last entry in the current tune params table is an int, > rather than something that is type-checked (like the penultimate entry - > an enum). Having the final entry be type checked at least ensures that > the right number of elements exist, even if the order is not strictly > checked. If you prefer, I can move "&generic_prefetch_tune" to the bottom of "struct= tune_params", thus enabling type checking on struct pointer. -- Maxim Kuvyrkov www.linaro.org