From: Borislav Petkov <bp@alien8.de>
To: Nadav Amit <namit@vmware.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Thomas Gleixner <tglx@linutronix.de>,
"H . Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>,
Richard Biener <rguenther@suse.de>,
Logan Gunthorpe <logang@deltatee.com>,
Sedat Dilek <sedat.dilek@gmail.com>,
Segher Boessenkool <segher@kernel.crashing.org>,
linux-arch <linux-arch@vger.kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Luc Van Oostenryck <luc.vanoostenryck@gmail.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
"virtualization@lists.linux-foundation.org"
<virtualization@lists.linux-foundation.org>,
Michal Marek <michal.lkml@markovi.net>,
"linux-sparse@vger.kernel.org" <linux-sparse@vger.kernel.org>,
Alok Kataria <akataria@vmware.com>,
Juergen Gross <jgross@suse.com>,
Andy Lutomirski <luto@kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>
Subject: Re: [PATCH] kbuild, x86: revert macros in extended asm workarounds
Date: Sun, 16 Dec 2018 11:00:42 +0100 [thread overview]
Message-ID: <20181216100042.GA815@zn.tnic> (raw)
In-Reply-To: <07BE39B2-1F99-4AE4-97F3-0871A39C5E7D@vmware.com>
On Sun, Dec 16, 2018 at 02:33:39AM +0000, Nadav Amit wrote:
> In general, I think that from the start it was clear that the motivation for
> the patch-set is not just performance and also better code. For example, I
> see no reason to revert the PV-changes or the lock-prefix changes that
> improved the code readability.
One thing that has caught my eye with the asm macros, which actually
decreases readability, is that I can't see the macro properly expanded
when I do
make <filename>.s
For example, I get
#APP
# 164 "./arch/x86/include/asm/cpufeature.h" 1
STATIC_CPU_HAS bitnum=$8 cap_byte="boot_cpu_data+35(%rip)" feature=123 t_yes=.L75 t_no=.L78 always=117 #, MEM[(const char *)&boot_cpu_data + 35B],,,,
# 0 "" 2
.loc 11 164 2 view .LVU480
#NO_APP
but I'd like to see the actual asm as it is really helpful when hacking
on inline asm stuff. And I haven't found a way to make gcc expand asm
macros in .s output.
Now, assuming the gcc inline patch will be backported to gcc8, I think
we should be covered on all modern distros going forward. So I think we
should revert at least the more complex macros.
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
next prev parent reply other threads:[~2018-12-16 10:00 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-13 9:17 [PATCH] kbuild, x86: revert macros in extended asm workarounds Masahiro Yamada
2018-12-13 10:51 ` Peter Zijlstra
2018-12-15 0:51 ` Masahiro Yamada
2018-12-16 2:33 ` Nadav Amit
2018-12-16 10:00 ` Borislav Petkov [this message]
2018-12-17 1:00 ` Nadav Amit
2018-12-17 9:16 ` Sedat Dilek
2018-12-18 19:33 ` 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=20181216100042.GA815@zn.tnic \
--to=bp@alien8.de \
--cc=akataria@vmware.com \
--cc=arnd@arndb.de \
--cc=hpa@zytor.com \
--cc=jgross@suse.com \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=logang@deltatee.com \
--cc=luc.vanoostenryck@gmail.com \
--cc=luto@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=mingo@redhat.com \
--cc=namit@vmware.com \
--cc=peterz@infradead.org \
--cc=rguenther@suse.de \
--cc=sedat.dilek@gmail.com \
--cc=segher@kernel.crashing.org \
--cc=tglx@linutronix.de \
--cc=virtualization@lists.linux-foundation.org \
--cc=x86@kernel.org \
--cc=yamada.masahiro@socionext.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox