All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nadav Amit <namit@vmware.com>
To: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"x86@kernel.org" <x86@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andy Lutomirski <luto@kernel.org>, Borislav Petkov <bp@alien8.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Denys Vlasenko <dvlasenk@redhat.com>
Subject: Re: [PATCH 2/6] x86: bug: prevent gcc distortions
Date: Fri, 18 May 2018 14:30:28 +0000	[thread overview]
Message-ID: <5C4B73C8-7BFC-4473-9ABD-6E23DD79A09A@vmware.com> (raw)
In-Reply-To: <20180518081354.GA11379@gmail.com>

Ingo Molnar <mingo@kernel.org> wrote:

> 
> * Peter Zijlstra <peterz@infradead.org> wrote:
> 
>> On Thu, May 17, 2018 at 09:13:58AM -0700, Nadav Amit wrote:
>>> +asm(".macro __BUG_FLAGS ins:req file:req line:req flags:req size:req\n"
>>> +    "1:\t \\ins\n\t"
>>> +    ".pushsection __bug_table,\"aw\"\n"
>>> +    "2:\t "__BUG_REL(1b)		"\t# bug_entry::bug_addr\n\t"
>>> +    __BUG_REL(\\file)			"\t# bug_entry::file\n\t"
>>> +    ".word \\line"			"\t# bug_entry::line\n\t"
>>> +    ".word \\flags"			"\t# bug_entry::flags\n\t"
>>> +    ".org 2b+\\size\n\t"
>>> +    ".popsection\n\t"
>>> +    ".endm");
>>> +
>>> +#define _BUG_FLAGS(ins, flags)                                          \
>>> do {									\
>>> +	asm volatile("__BUG_FLAGS \"" ins "\" %c0 %c1 %c2 %c3"		\
>>> +		     : : "i" (__FILE__), "i" (__LINE__),                \
>>> +			 "i" (flags),                                   \
>>> 			 "i" (sizeof(struct bug_entry)));		\
>>> } while (0)
>> 
>> This is an awesome hack, but is there really nothing we can do to make
>> it more readable? Esp, that global asm doing the macro definition is a
>> pain to read.
>> 
>> Also, can we pretty please used named operands in 'new' code?
> 
> Yes, that's my main worry too about all these inlining changes:
> the very, very marked reduction in the readability of assembly code.
> 
> It's bad to an extent that I'm questioning the wisdom of pandering to a compiler 
> limitation to begin with?
> 
> How about asking GCC for an attribute where we can specify the inlined size of an 
> asm() function? Even if we'll just approximate it due to some vagaries of actual 
> code generation related to how arguments interact with GCC, an explicit byte value 
> will do a heck of a better job of it than some sort of implied, vague 'number of 
> newlines' heuristics ...

If it were to become a GCC feature, I think it is best to be a builtin that
says: consider the enclosed expression as “free”. The problem of poor
inlining decisions is not specific to inline asm. As I mentioned in the RFC,
when there are two code paths for constants and variables based on
__builtin_constant_p(), you can get the “cost” of the constant path for
variables.

It is not hard to add such a feature to GCC, but I don’t know how easy it is
to get new features into the compiler.

  parent reply	other threads:[~2018-05-18 14:30 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 16:13 [PATCH 0/6] Macrofying inline assembly for better compilation Nadav Amit
2018-05-17 16:13 ` Nadav Amit
2018-05-17 16:13 ` [PATCH 1/6] x86: objtool: use asm macro for better compiler decisions Nadav Amit
2018-05-17 16:13   ` Nadav Amit
2018-05-17 16:13 ` [PATCH 2/6] x86: bug: prevent gcc distortions Nadav Amit
2018-05-18  7:58   ` Peter Zijlstra
2018-05-18  8:13     ` Ingo Molnar
2018-05-18 10:11       ` Borislav Petkov
2018-05-18 14:36         ` Nadav Amit
2018-05-18 15:40           ` Borislav Petkov
2018-05-18 15:46             ` Nadav Amit
2018-05-18 15:53               ` Borislav Petkov
2018-05-18 16:29                 ` Nadav Amit
2018-05-18 17:41                   ` Boris Petkov
2018-05-18 14:30       ` Nadav Amit [this message]
2018-05-18 14:22     ` Nadav Amit
2018-05-18 17:52       ` Joe Perches
2018-05-18 16:24     ` Linus Torvalds
2018-05-18 17:24       ` Nadav Amit
2018-05-18 18:25         ` Linus Torvalds
2018-05-18 18:33           ` hpa
2018-05-18 18:50             ` Linus Torvalds
2018-05-18 18:53               ` hpa
2018-05-18 19:02                 ` Nadav Amit
2018-05-18 19:05                   ` hpa
2018-05-18 19:11                   ` Linus Torvalds
2018-05-18 19:18                     ` Nadav Amit
2018-05-18 19:21                       ` Linus Torvalds
2018-05-18 19:22                         ` hpa
2018-05-18 19:36                           ` Nadav Amit
2018-05-18 19:41                             ` hpa
2018-05-17 16:13 ` [PATCH 3/6] x86: alternative: macrofy locks for better inlining Nadav Amit
2018-05-17 16:14 ` [PATCH 4/6] x86: prevent inline distortion by paravirt ops Nadav Amit
2018-05-17 16:14 ` [PATCH 5/6] x86: refcount: prevent gcc distortions Nadav Amit
2018-05-19  4:27   ` kbuild test robot
2018-05-17 16:14 ` [PATCH 6/6] x86: removing unneeded new-lines Nadav Amit
2018-05-18  9:20 ` [PATCH 0/6] Macrofying inline assembly for better compilation David Laight
2018-05-18  9:20 ` David Laight
2018-05-18 14:15   ` Nadav Amit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5C4B73C8-7BFC-4473-9ABD-6E23DD79A09A@vmware.com \
    --to=namit@vmware.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=bp@alien8.de \
    --cc=dvlasenk@redhat.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=torvalds@linux-foundation.org \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.