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=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS,USER_AGENT_MUTT 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 68AE6C43441 for ; Wed, 10 Oct 2018 19:55:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 1D8C0206B2 for ; Wed, 10 Oct 2018 19:55:11 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1D8C0206B2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org 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 S1727598AbeJKDSm (ORCPT ); Wed, 10 Oct 2018 23:18:42 -0400 Received: from gate.crashing.org ([63.228.1.57]:36179 "EHLO gate.crashing.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727360AbeJKDSm (ORCPT ); Wed, 10 Oct 2018 23:18:42 -0400 Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id w9AIseq1011514; Wed, 10 Oct 2018 13:54:41 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id w9AIsZJK011445; Wed, 10 Oct 2018 13:54:35 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Wed, 10 Oct 2018 13:54:33 -0500 From: Segher Boessenkool To: Borislav Petkov Cc: Ingo Molnar , Richard Biener , Michael Matz , 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 Message-ID: <20181010185432.GB29268@gate.crashing.org> References: <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> <20181010081906.GA5533@zn.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181010081906.GA5533@zn.tnic> User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Oct 10, 2018 at 10:19:06AM +0200, Borislav Petkov wrote: > On Wed, Oct 10, 2018 at 03:03:25AM -0500, Segher Boessenkool wrote: > > 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. > > Thanks for implementing this, much appreciated. If you need people to > test stuff, lemme know. It would be great to hear from kernel people if it works adequately for what you guys want it for :-) > > 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. > > My only concern is how we would catch the other extremity where the > inline asm grows too big and we end up inlining it everywhere and thus > getting fat. The 0day bot already builds tinyconfigs but we should be > looking at vmlinux size growth too. But this isn't really different from other always_inline concerns afaics? So you should be able to catch it the same way, too. Segher From mboxrd@z Thu Jan 1 00:00:00 1970 From: Segher Boessenkool Subject: Re: PROPOSAL: Extend inline asm syntax with size spec Date: Wed, 10 Oct 2018 13:54:33 -0500 Message-ID: <20181010185432.GB29268@gate.crashing.org> References: <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> <20181010081906.GA5533@zn.tnic> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Content-Disposition: inline In-Reply-To: <20181010081906.GA5533@zn.tnic> To: Borislav Petkov Cc: Ingo Molnar , Richard Biener , Michael Matz , 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 List-Id: linux-sparse@vger.kernel.org On Wed, Oct 10, 2018 at 10:19:06AM +0200, Borislav Petkov wrote: > On Wed, Oct 10, 2018 at 03:03:25AM -0500, Segher Boessenkool wrote: > > 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. > > Thanks for implementing this, much appreciated. If you need people to > test stuff, lemme know. It would be great to hear from kernel people if it works adequately for what you guys want it for :-) > > 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. > > My only concern is how we would catch the other extremity where the > inline asm grows too big and we end up inlining it everywhere and thus > getting fat. The 0day bot already builds tinyconfigs but we should be > looking at vmlinux size growth too. But this isn't really different from other always_inline concerns afaics? So you should be able to catch it the same way, too. Segher