From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94885 invoked by alias); 17 Sep 2019 21:11:12 -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 94877 invoked by uid 89); 17 Sep 2019 21:11:12 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.1 spammy=H*Ad:U*rth, HX-Received:90a X-HELO: mail-pf1-f176.google.com Received: from mail-pf1-f176.google.com (HELO mail-pf1-f176.google.com) (209.85.210.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 17 Sep 2019 21:11:10 +0000 Received: by mail-pf1-f176.google.com with SMTP id q10so2896559pfl.0 for ; Tue, 17 Sep 2019 14:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:openpgp:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=G5A2sKgkUm2X8npfxeuh2/o4xTsoTnur9d9GQXiAdhw=; b=DK6cbbb/kkW1Bvs86CaZ/q8bQ6DflxZ39awhYqhX4M5HVN+XUhx1Iv2oBU1xaDh2kh aZa2n8DbrIxmB2rsxpn3bYwiu/29lyujJlHSYd+JxvIURJCYrqzUQb6YqW1uxSk438Ic jXcTGhBpuC201x0DONikrSn0VNiFjTOl7Iv0f56qUMCf+KJczZJcyjmcQ4yN4pR/mKIG Mdj1knOZdjvyUdlpIzuKEgjLL51qq/m/CNVC2cX2BNYJTvkhmKVoxYUb7sLCGyWgrqwU qawcuqL/q/kTYkMbUA9BsK3hvUyVEXNj1SUFbp5eQVcSvr7zdX3cB8iIh18RPkcXTz2f vVHw== Return-Path: Received: from [192.168.1.11] (97-113-7-119.tukw.qwest.net. [97.113.7.119]) by smtp.googlemail.com with ESMTPSA id i16sm1611373pfa.184.2019.09.17.14.11.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Sep 2019 14:11:07 -0700 (PDT) Subject: Re: [PATCH, AArch64, v3 0/6] LSE atomics out-of-line To: Wilco Dijkstra , Kyrill Tkachov , Richard Henderson , GCC Patches Cc: nd , Ramana Radhakrishnan , "agraf@suse.de" , Marcus Shawcroft , James Greenhalgh References: <5c4cbe49-8613-b9e4-9011-df26ced40a35@linaro.org> <790aabf8-5edc-eb7a-b4ec-cccef74e403a@foss.arm.com> From: Richard Henderson Openpgp: preference=signencrypt Message-ID: <93a4e0fc-c644-ba92-b910-20cdb5b6fedc@twiddle.net> Date: Tue, 17 Sep 2019 21:11:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg01032.txt.bz2 On 9/17/19 6:55 AM, Wilco Dijkstra wrote: > Hi Kyrill, > >>> When you select a CPU the goal is that we optimize and schedule for that >>> specific microarchitecture. That implies using atomics that work best for >>> that core rather than outlining them. >> >> I think we want to go ahead with this framework to enable the portable >> deployment of LSE atomics. >> >> More CPU-specific fine-tuning can come later separately. > > I'm not talking about CPU-specific fine-tuning, but ensuring we don't penalize > performance when a user selects the specific CPU their application will run on. > And in that case outlining is unnecessary. >From aarch64_override_options: Given both -march=foo -mcpu=bar, then the architecture will be foo and -mcpu will be treated as -mtune=bar, but will not use any insn not in foo. Given only -mcpu=foo, then the architecture will be the one supported by foo. So if foo supports LSE, then we will not outline the functions, no matter how we arrive at foo. r~