mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Andrey Ryabinin <aryabinin@virtuozzo.com>
To: Josh Poimboeuf <jpoimboe@redhat.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Cc: the arch/x86 maintainers <x86@kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Ingo Molnar <mingo@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>,
	Andy Lutomirski <luto@kernel.org>,
	Alexander Potapenko <glider@google.com>,
	Dmitriy Vyukov <dvyukov@google.com>,
	Matthias Kaehlcke <mka@chromium.org>,
	Arnd Bergmann <arnd@arndb.de>,
	Peter Zijlstra <peterz@infradead.org>
Subject: Re: [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent
Date: Fri, 15 Sep 2017 19:53:46 +0300	[thread overview]
Message-ID: <96dcfb0d-75b9-9707-67df-9bae33186b7d@virtuozzo.com> (raw)
In-Reply-To: <20170831172542.k5qchwmgckdcnc6d@treble>



On 08/31/2017 08:25 PM, Josh Poimboeuf wrote:
>
> There have been a few other ideas which have *almost* worked:
> 
> 1) Make the 'register void *__sp asm(_ASM_SP)' a global variable instead
>    of a local one.  This works for GCC and doesn't break clang.  However
>    it resulted in a lot of changed code on the GCC side.  It looked like
>    some optimizations had been disabled, even in functions which
>    shouldn't have been affected.
> 

(For those who wasn't following previous discussion there is the patch - http://lkml.kernel.org/r/<75850bb7-a60e-057d-d88b-afa0c79e94a0@gmail.com>
But, Josh discovered that the patch causes regression in .text size with gcc > 7.x
http://lkml.kernel.org/r/<20170721132452.ihpws67e3e7ym3al@treble> )

I'm not so sure that this is disabled optimization. I assume that global rsp makes
changes something in gcc's register allocation logic, or something like that leading
to subtle changes in generated code.

But what I recently find out, is that this "regression" sometimes is actually improvement in .text size.
It all depends on .config, e.g:


allnoconfig:
               text    data     bss     dec     hex filename
patched	       938094  207700 1215752 2361546  2408ca allnoconfig_p/vmlinux
unpatched      938768  211796 1215752 2366316  241b6c allnoconfig/vmlinux                                                                                                                                                         


defconfig:
               text    data     bss     dec     hex filename
patched	       10691469        4882856  876544 16450869         fb0535 defconfig_p/vmlinux
unpatched      10691035        4882856  876544 16450435         fb0383 defconfig/vmlinux

allyesconfig:
               text    data     bss     dec     hex filename
patched	       159216239       153294411       49692672        362203322       1596c8ba        allyesconfig_p/vmlinux
unpatched      159224951       153294387       49692672        362212010       1596eaaa        allyesconfig/vmlinux


So there is regression with Josh's config and defconfig, but allnoconfig and allyesconfig shows improvement.
Note that sometimes there is the difference in .data size too, don't ask me why.

Given that, perhaps the best thing to do here would be asking gcc devs why is generated code changed.
And if such changes are harmless (as I suspect) we can just fix the problem with this simple patch http://lkml.kernel.org/r/<75850bb7-a60e-057d-d88b-afa0c79e94a0@gmail.com> ?
Despite the increased .text on some configs.

  parent reply	other threads:[~2017-09-15 16:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-31 14:11 [RFC PATCH 0/4] x86/asm: Add ASM_CALL() macro for inline asms with call instructions Josh Poimboeuf
2017-08-31 14:11 ` [RFC PATCH 1/4] x86/paravirt: Fix output constraint macro names Josh Poimboeuf
2017-08-31 14:11 ` [RFC PATCH 2/4] x86/asm: Convert some inline asm positional operands to named operands Josh Poimboeuf
2017-08-31 14:11 ` [RFC PATCH 3/4] x86/asm: Make alternative macro interfaces more clear and consistent Josh Poimboeuf
2017-08-31 16:11   ` Linus Torvalds
2017-08-31 17:25     ` Josh Poimboeuf
2017-08-31 17:31       ` Josh Poimboeuf
2017-09-02 10:32         ` Ingo Molnar
2017-09-14 14:48           ` Josh Poimboeuf
2017-09-14 17:16             ` Linus Torvalds
2017-09-14 17:26               ` Josh Poimboeuf
2017-09-14 17:33                 ` Josh Poimboeuf
2017-09-14 18:28                   ` Linus Torvalds
2017-09-14 18:45                     ` Josh Poimboeuf
2017-09-15 16:10                       ` Josh Poimboeuf
2017-09-15 16:53       ` Andrey Ryabinin [this message]
2017-09-15 17:20         ` Josh Poimboeuf
2017-09-15 18:01         ` Linus Torvalds
2017-09-15 23:29           ` Josh Poimboeuf
2017-09-16 22:22             ` Andrey Ryabinin
2017-09-18 17:40               ` Josh Poimboeuf
2017-09-19 16:02           ` Josh Poimboeuf
2017-08-31 14:11 ` [RFC PATCH 4/4] x86/asm: Use ASM_CALL() macro for inline asm statements with call instructions Josh Poimboeuf
2017-08-31 14:50   ` Peter Zijlstra
2017-08-31 15:21     ` Josh Poimboeuf
2017-08-31 15:36       ` Dmitry Vyukov

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=96dcfb0d-75b9-9707-67df-9bae33186b7d@virtuozzo.com \
    --to=aryabinin@virtuozzo.com \
    --cc=arnd@arndb.de \
    --cc=dvyukov@google.com \
    --cc=glider@google.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mingo@kernel.org \
    --cc=mka@chromium.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®