From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 98266 invoked by alias); 11 Nov 2018 23:41:26 -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 98257 invoked by uid 89); 11 Nov 2018 23:41:25 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=entertaining X-HELO: mail-qk1-f194.google.com Received: from mail-qk1-f194.google.com (HELO mail-qk1-f194.google.com) (209.85.222.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 11 Nov 2018 23:41:24 +0000 Received: by mail-qk1-f194.google.com with SMTP id a132so10607586qkg.1 for ; Sun, 11 Nov 2018 15:41:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=uyKIIqeed94qbA0rY6epDIvKCGzBluESEp29DR1f70E=; b=vhKm8DnaThqOo3bMhJmFgCCk4EcOsO+gKqz6sjjzefRCyPTsNC2ejrKZ6aEbZkuXpC niRGjgdGk4xUvhG2Jo38zjUEqbfzhJq5pwEyLoBJHnE5FeUtX1Qjkoeupz9vAfsUwVPm MEMNXPXhjklxPD42ci6O0CWvr/zVlteB6RFm/hzTfxwHNBIWR6AjhKed935JZRRFULmR xBdBvoUYqiByk0sSlh82Sa8/jOiOAUEy2+Yt0Nk19nZR8MdIUr+AjvaTVnq+UKjQ6QMq FCTfBgag/MM1mmBWqyWmqZ6rWozlNYtkBQbEkc5z3vi1wD9Wrrv2/xiwnVR5ytKnX1Pk tohg== Return-Path: Received: from localhost.localdomain (184-96-239-209.hlrn.qwest.net. [184.96.239.209]) by smtp.gmail.com with ESMTPSA id y46-v6sm10253135qty.42.2018.11.11.15.41.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 11 Nov 2018 15:41:21 -0800 (PST) Subject: Re: [PATCH 2/2] asm inline To: Segher Boessenkool References: <72103970-b2be-a641-a0a5-d08609f62f5f@gmail.com> <20181111220057.GF23873@gate.crashing.org> Cc: gcc-patches@gcc.gnu.org, jakub@redhat.com From: Martin Sebor Message-ID: <253e4890-31ce-3e49-f863-e976d2083fa0@gmail.com> Date: Sun, 11 Nov 2018 23:41:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20181111220057.GF23873@gate.crashing.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-11/txt/msg00878.txt.bz2 On 11/11/2018 03:00 PM, Segher Boessenkool wrote: > On Sun, Nov 11, 2018 at 02:33:34PM -0700, Martin Sebor wrote: >> On 10/30/2018 11:30 AM, Segher Boessenkool wrote: >>> The Linux kernel people want a feature that makes GCC pretend some >>> inline assembler code is tiny (while it would think it is huge), so >>> that such code will be inlined essentially always instead of >>> essentially never. >>> >>> This patch lets you say "asm inline" instead of just "asm", with the >>> result that that inline assembler is always counted as minimum cost >>> for inlining. It implements this for C and C++. >> >> Rather than overloading the inline keyword I think it would be >> more in keeping both with the design of existing features to >> control inlining in GCC and with the way the languages are >> evolving to allow the always_inline (and perhaps also noinline) >> attribute to apply to asm statements. > > We already "overloaded" the volatile and goto keywords here (it's not > overloading, the contexts are completely disjoint). > > always_inline is a function attribute, and you want to make it a statement > attribute (which we do not currently support except for empty statements!) > as well. Yes, I suggest using a statement attribute for this. I believe it would be more appropriate that overloading the meaning of an existing keyword in this context. C++ is entertaining proposals to introduce a few statement attributes (e.g., likely/unlikely and even unreachable) so as I said, adding one to GCC would be in like with the direction the languages are moving (C has adopted the C++ 11 attributes for C2X and it likely will continue to do so going forward). Supporting an attribute in this context also has a lower cost for third party tools that parse code (and are already prepared to deal with attributes). Adding a new keyword here has a good chance of breaking some of those tools. >> The inline keyword is commonly understood to be just a hint to >> the compiler. > > That is exactly what it is here. It hints the compiler that this asm > is cheap, whatever it may look like. The way you described the purpose of asm inline: "such code will be inlined essentially always instead of essentially never" sounded to me like it's close to the effect of attribute always_inline. But after reading the patch it looks like the asm just overrides the number of instructions GCC estimates the statement expands into. If I read the code right then a different attribute altogether would seem more appropriate (e.g., perhaps even something like insn_count (N); that would make it possible to provide an exact instruction count and also prevent the inlining of the enclosing function by specifying a very large count). In any event, overloading the inline keyword for this purpose doesn't seem like a good approach to me. Martin