All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Vladimir Makarov <vmakarov@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>,
	Richard Henderson <rth@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Borislav Petkov <bp@alien8.de>
Subject: Re: [PATCH] x86: Optimize variable_test_bit()
Date: Fri, 1 May 2015 13:49:52 -0700	[thread overview]
Message-ID: <CA+55aFxOd6mJcezgoLHN9Zgds-CsJqsx4Jgkp9OP1xUf11727Q@mail.gmail.com> (raw)
In-Reply-To: <5543CDC0.6010206@redhat.com>

On Fri, May 1, 2015 at 12:02 PM, Vladimir Makarov <vmakarov@redhat.com> wrote:
>
>   GCC RA is a major reason to prohibit output operands for asm goto.

Hmm.. Thinking some more about it, I think that what would actually
work really well at least for the kernel is:

(a) allow *memory* operands (ie "=m") as outputs and having them be
meaningful even at any output labels (obviously with the caveat that
the asm instructions that write to memory would have to happen before
the branch ;)

This covers the somewhat common case of having magic instructions that
result in conditions that can't be tested at a C level. Things like
"bit clear and test" on x86 (with or without the lock) .

 (b) allow other operands to be meaningful onlty for the fallthrough case.

>From a register allocation standpoint, these should be the easy cases.
(a) doesn't need any register allocation of the output (only on the
input to set up the effective address of the memory location), and (b)
would explicitly mean that an "asm goto" would leave any non-memory
outputs undefined in any of the goto cases, so from a RA standpoint it
ends up being equivalent to a non-goto asm..

Hmm?

So as an example of something that the kernel does and which wants to
have an output register. is to do a load from user space that can
fault. When it faults, we obviously simply don't *have* an actual
result, and we return an error. But for the successful fallthrough
case, we get a value in a register.

I'd love to be able to write it as (this is simplified, and doesn't
worry about all the different access sizes, or the "stac/clac"
sequence to enable user accesses on modern Intel CPU's):

        asm goto(
            "1:"
            "\tmovl %0,%1\n"
            _ASM_EXTABLE(1b,%l[error])
            : "=r" (val)
            : "m" (*userptr)
            : : error);

where that "_ASM_EXTABLE()" is our magic macro for generating an
exception entry for that instruction, so that if the load takes an
exception, it will instead to to the "error" label.

But if it goes to the error label, the "val" output register really
doesn't contain anything, so we wouldn't even *want* gcc to try to do
any register allocation for the "jump to label from assembly" case.

So at least for one of the major cases that I'd like to use "asm goto"
with an output, I actually don't *want* any register allocation for
anything but the fallthrough case. And I suspect that's a
not-too-uncommon pattern - it's probably often about error handling.

                        Linus

  reply	other threads:[~2015-05-01 20:49 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-01 15:16 [PATCH] x86: Optimize variable_test_bit() Peter Zijlstra
2015-05-01 16:03 ` Linus Torvalds
2015-05-01 16:16   ` Peter Zijlstra
2015-05-01 16:29     ` Peter Zijlstra
2015-05-01 16:18   ` Peter Zijlstra
2015-05-01 16:33   ` Jakub Jelinek
2015-05-01 16:45     ` Linus Torvalds
2015-05-01 16:46     ` Peter Zijlstra
2015-05-01 17:17       ` Ingo Molnar
2015-05-01 19:02     ` Vladimir Makarov
2015-05-01 20:49       ` Linus Torvalds [this message]
2015-05-01 22:22         ` Vladimir Makarov
2015-05-02 12:39         ` Peter Zijlstra
2015-05-04 15:37           ` Richard Henderson
2015-05-04 19:33           ` [RFC] Design for flag bit outputs from asms Richard Henderson
2015-05-04 20:14             ` H. Peter Anvin
2015-05-04 20:27               ` H. Peter Anvin
2015-05-04 20:33               ` Richard Henderson
2015-05-04 20:45                 ` Linus Torvalds
2015-05-04 20:57                   ` Richard Henderson
2015-05-04 21:23                     ` H. Peter Anvin
2015-05-04 20:35               ` Linus Torvalds
2015-05-04 20:42                 ` H. Peter Anvin
2015-05-05  9:01             ` Gabriel Paubert
2015-05-05 13:50             ` Segher Boessenkool
2015-05-05 15:37               ` Linus Torvalds
2015-05-05 16:10                 ` Segher Boessenkool
2015-05-02 12:43       ` [PATCH] x86: Optimize variable_test_bit() Peter Zijlstra
2015-05-04 18:07         ` Vladimir Makarov
2015-05-04 20:14           ` H. Peter Anvin
2015-05-04 13:42 ` Peter Zijlstra

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=CA+55aFxOd6mJcezgoLHN9Zgds-CsJqsx4Jgkp9OP1xUf11727Q@mail.gmail.com \
    --to=torvalds@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jakub@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rth@redhat.com \
    --cc=tglx@linutronix.de \
    --cc=vmakarov@redhat.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 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.