From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: PROPOSAL: Extend inline asm syntax with size spec Date: Mon, 8 Oct 2018 08:13:23 +0200 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-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: virtualization-bounces@lists.linux-foundation.org Errors-To: virtualization-bounces@lists.linux-foundation.org To: Michael Matz Cc: Kate Stewart , Peter Zijlstra , Christopher Li , virtualization@lists.linux-foundation.org, Masahiro Yamada , Nadav Amit , Jan Beulich , "H. Peter Anvin" , Sam Ravnborg , Thomas Gleixner , x86@kernel.org, linux-sparse@vger.kernel.org, Ingo Molnar , linux-xtensa@linux-xtensa.org, Kees Cook , Segher Boessenkool , Chris Zankel , Borislav Petkov , Josh Poimboeuf , Alok Kataria , Juergen Gross , gcc@gcc.gnu.org, Richard Biener , Max Filippov , Greg Kroah-Hartman List-Id: linux-sparse@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