From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 52F9AC43441 for ; Wed, 10 Oct 2018 10:29:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 11FD020835 for ; Wed, 10 Oct 2018 10:29:10 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 11FD020835 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726665AbeJJRui (ORCPT ); Wed, 10 Oct 2018 13:50:38 -0400 Received: from mx2.suse.de ([195.135.220.15]:39548 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726022AbeJJRui (ORCPT ); Wed, 10 Oct 2018 13:50:38 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 0D4B2AFBB; Wed, 10 Oct 2018 10:29:06 +0000 (UTC) Date: Wed, 10 Oct 2018 12:29:03 +0200 (CEST) From: Richard Biener To: Segher Boessenkool cc: Ingo Molnar , Michael Matz , Borislav Petkov , gcc@gcc.gnu.org, Nadav Amit , Ingo Molnar , linux-kernel@vger.kernel.org, x86@kernel.org, Masahiro Yamada , Sam Ravnborg , Alok Kataria , Christopher Li , Greg Kroah-Hartman , "H. Peter Anvin" , Jan Beulich , Josh Poimboeuf , Juergen Gross , Kate Stewart , Kees Cook , linux-sparse@vger.kernel.org, Peter Zijlstra , Philippe Ombredanne , Thomas Gleixner , virtualization@lists.linux-foundation.org, Linus Torvalds , Chris Zankel , Max Filippov , linux-xtensa@linux-xtensa.org, Andrew Morton Subject: Re: PROPOSAL: Extend inline asm syntax with size spec In-Reply-To: <20181010080324.GV29268@gate.crashing.org> Message-ID: References: <20181003213100.189959-1-namit@vmware.com> <20181007091805.GA30687@zn.tnic> <20181007132228.GJ29268@gate.crashing.org> <20181008073128.GL29268@gate.crashing.org> <20181009145330.GT29268@gate.crashing.org> <20181010072240.GB103159@gmail.com> <20181010080324.GV29268@gate.crashing.org> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 10 Oct 2018, Segher Boessenkool wrote: > On Wed, Oct 10, 2018 at 09:22:40AM +0200, Ingo Molnar wrote: > > * Richard Biener wrote: > > > Can kernel folks give this a second and third thought please so we > > > don't implement sth that in the end won't satisfy you guys? > > > > So this basically passes '0 size' to the inliner, which should be better > > than passing in the explicit size, as we'd inevitably get it wrong > > in cases. > > The code immediately after this makes it size 1, even for things like > asm(""), I suppose this works better for the inliner. But that's a detail > (and it might change); the description says "consider this asm as minimum > length and cost for inlining decisions", which works for either 0 or 1. It was made 1 as otherwise the inliner happily explodes on void foo () { asm(""); foo(); } > > I also like 'size 0' for the reason that we tend to write assembly code > > and mark it 'inline' if we really think it matters to performance, > > so making it more likely to be inlined when used within another inline > > function is a plus as well. > > You can think of it as meaning "we want this asm inlined always", and then > whether that actually happens depends on if the function around it is > inlined or not. Richard.