Received: by 2002:ac0:a582:0:0:0:0:0 with SMTP id m2-v6csp3209107imm; Sun, 7 Oct 2018 23:15:07 -0700 (PDT) X-Google-Smtp-Source: ACcGV60HKztA18wGQGSZCLok1AzfcC2/GFbX1EQZ+7CENZVg8gA6hfKf/Muz8GzEZYOTsRS5p9oN X-Received: by 2002:a63:cc:: with SMTP id 195-v6mr19551078pga.44.1538979307248; Sun, 07 Oct 2018 23:15:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538979307; cv=none; d=google.com; s=arc-20160816; b=K0L+daG21IXyqcxcqiZ6PXIanfjZInNzK8XhDA+9JT1qZNavzXCDCIC2sjVuhT+Xp4 3Sbhk+6gzMA/OG8JJeAy86iP2e4dDhpmyBRa2ynyxibxlqN/njnjxVuowCJwnzU9YKXn ff3OawloYOatFcgmDFUhN/Jp+sclkp4AJqi4U92VyU7DhrCj0IOAEJs7gL0HQ+nOSmHr OsbwtBTpet4+m1g7tERWJZzCU0A1z94ntkPgC8E9BoYmb6uiSYEkOj6+guTOBMR4l+gz G+3ZzZD/F5P0kA9CFDjApATIKC/cROkEnktsQ/LC+sijmpaGtKQhT9VnCT6D50iBZs1B iZzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=MNPVj+A/IaZ7n9FRa9xC3L12i3eMs0Se4OmDXxEJ8xA=; b=bSm/R5G8u65Z0unOleIjbGSCWlJ0z2fy9AViU+WzzVtZiMazqiM5bSrVrV6spiR//n QhM5U61LsoSFyejhOzGwSSrnYU2lCyKJZEHg/dvONP54iFEq5E50lblzCCs75qEe/ozW j7CtQHY/EwCy6abpF30EdCIdoj8fVxIgcVeETy5fQTGCvdf1hr90o03/ccIO9G8Uzvfy ZZtjwchIktfRxwNen5vnq5/j1uOj4xqWTHBzxW6cCgRAIJzoWKLrFvpbIgh7TrTR6WPq RUtRCwIPiRTwRhh8JjuvpZzsjpsA/AGa/bvv0oSxgON/rcCdrZHfSoF9pR4HZB1JLYO6 7TQA== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=pX3DhbXz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b20-v6si16298027pgk.360.2018.10.07.23.14.52; Sun, 07 Oct 2018 23:15:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@gmail.com header.s=20161025 header.b=pX3DhbXz; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726721AbeJHNXc (ORCPT + 99 others); Mon, 8 Oct 2018 09:23:32 -0400 Received: from mail-wr1-f67.google.com ([209.85.221.67]:44024 "EHLO mail-wr1-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725950AbeJHNXb (ORCPT ); Mon, 8 Oct 2018 09:23:31 -0400 Received: by mail-wr1-f67.google.com with SMTP id n1-v6so19353687wrt.10; Sun, 07 Oct 2018 23:13:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=MNPVj+A/IaZ7n9FRa9xC3L12i3eMs0Se4OmDXxEJ8xA=; b=pX3DhbXzt/iP5uDIOGjZUe5fL/BkB2L79dmdhnJ9ZqgQYYbHvCmrFpD4Ob9srycAZ6 925g6v0UDEGafmBHSgWI0M+cJepNBUe37HoBmq0W44CfVJJPIxHIrXk/fVGqIwfoUccO CJVNvkEowp+tqAoMA4YVj+EmE85f2cxf9Ii/13bSe8LwsMczHN9x0NoMAMurqx8+NjLC NJxsf85E1i9UkMHvQonTLnupKmRvkHxAmLQ7I7gl3mQtbNlkIJ9choDRZu/I+FTpoHZn XqIJBJbhws9vDpkwFmkNHG24dV040JGpnGrd2KU+PdlP/+KqBHJB6Q9mZlUwL+TGoZ3W hnkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to:user-agent; bh=MNPVj+A/IaZ7n9FRa9xC3L12i3eMs0Se4OmDXxEJ8xA=; b=AkwjjzLw4z8RkjPJUASfvfLkJpG1pU4BclWFZ5tUwpna2zg5fzJiD3ROW1Z0NkydIh u/6t2P+iC+PRF3INkoeJsYRGliQmW6koVTmPmLQOibNbU7SW+VaCig3Vh92gllUMfnwG gPZLDfTCJJpvZLCSbQ8C+sQk/sdybZnyvP66+bBxdwVoVXjRs9npLWaLo46Ni7OBrYpt 8Yx55mQC/+jvNBEcvjxEwe9i4SBFP+IBkjbp6mpXSkUHQAmoEK+4oi8kCiIlA7WcXbnb qJ9lSi3LGV0JHWmNbhGX9CJj1DZrTQR5793Wld/F26reUpuHn81/NhZ9aRjw7J4Ov2QG kroQ== X-Gm-Message-State: ABuFfoh98bsZMRjm47pEsP1kDovSvyKrDBMsXZCBCm3DymgPVfCmCA3G 8J5Tx6PHg9pAXcOSD3FQ9vY= X-Received: by 2002:a5d:6b4f:: with SMTP id x15-v6mr12937047wrw.304.1538979207114; Sun, 07 Oct 2018 23:13:27 -0700 (PDT) Received: from gmail.com (2E8B0CD5.catv.pool.telekom.hu. [46.139.12.213]) by smtp.gmail.com with ESMTPSA id v106-v6sm26954117wrc.85.2018.10.07.23.13.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Sun, 07 Oct 2018 23:13:26 -0700 (PDT) Date: Mon, 8 Oct 2018 08:13:23 +0200 From: Ingo Molnar To: Michael Matz Cc: Segher Boessenkool , Borislav Petkov , gcc@gcc.gnu.org, Richard Biener , 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 Subject: Re: PROPOSAL: Extend inline asm syntax with size spec Message-ID: <20181008061323.GB66819@gmail.com> References: <20181003213100.189959-1-namit@vmware.com> <20181007091805.GA30687@zn.tnic> <20181007132228.GJ29268@gate.crashing.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org * Michael Matz wrote: > (without an built-in assembler which hopefully noone proposes). There are disadvantages (the main one is having to implement it), but a built-in assembler has numerous advantages as well: - Better optimizations: for example -Os could more accurately estimate true instruction size. - Better inlining: as the examples in this thread are showing. - Better padding/alignment: right now GCC has no notion about the precise cache layout of the assembly code it generates and the code alignment options it has are crude. It got away with this so far because the x86 rule of thumb is that dense code is usually the right choice. - Better compiler performance: it would be faster as well to immediately emit assembly instructions, just like GCC's preprocessor library use speeds up compilation *significantly* instead of creating a separate preprocessor task. - Better future integration of assembly blocks: GCC could begin to actually understand the assembly statements in inline asm and allow more user-friendly extensions to its historically complex and difficult to master inline asm syntax. I mean, it's a fact that the GNU project has *already* defined their own assembly syntax which departs from decades old platform assembly syntax - and how the assembler is called by the compiler is basically an implementation detail, not a conceptual choice. The random multi-process unidirectional assembler choice of the past should not be treated as orthodoxy. Thanks, Ingo