linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Uros Bizjak <ubizjak@gmail.com>
Cc: Borislav Petkov <bp@suse.de>, x86-ml <x86@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] x86/asm updates for v5.10
Date: Mon, 12 Oct 2020 12:03:18 -0700	[thread overview]
Message-ID: <CAHk-=wgBHgmAoLG9A0b-2_2ZiL_OaXLyO2pbKOHm=u93NttSBQ@mail.gmail.com> (raw)
In-Reply-To: <CAHk-=whbEhjSHR7D=8Q_xARd=UKHGcz750LoT1BeRdgTR+6uSw@mail.gmail.com>

On Mon, Oct 12, 2020 at 11:56 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> I also find that clang generates code that uses the high byte
> registers, although again, that's not from any knowledge of clang
> internals, and just by looking at my kernel image disassembly.
>
> So yes, it _may_ all be just peepholes, but it's not obvious that this
> is all safe.

The clang use I find seems to be _purely_ for variations of "mov", and
only ever with the high register as a source.

So yes, that one looks very much like a peephole optimization where
clang just recognizes patterns line

     X = (y >> 8) & 0xff;

and uses a "movzbl %*h,xyz" for it.

Gcc actually seems to use high registers more, but the extended use
seems to be bit test (and set) operations that also may be simply
peepholes.

So yes, from code generation patterns it does look likely that neither
compiler actually considers the high registers to be truely
independent entities, and thus quite likely that you'd never find
concurrent mixed use.

But that really seems to be an implementation issue rather than
something we should necessarily rely on, unless we have a stronger
statement from both compiler camps..

              Linus

  parent reply	other threads:[~2020-10-12 19:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-12 11:05 [GIT PULL] x86/asm updates for v5.10 Borislav Petkov
2020-10-12 18:11 ` Linus Torvalds
     [not found]   ` <CAFULd4Z1_UKN6haGbNJMi0_tGddPZcawRDfoYnLdn-Qe6UR3-Q@mail.gmail.com>
2020-10-12 18:55     ` Borislav Petkov
2020-10-12 20:29       ` Arvind Sankar
2020-10-12 18:56     ` Linus Torvalds
2020-10-12 18:59       ` Borislav Petkov
2020-10-12 19:03       ` Linus Torvalds [this message]
     [not found]         ` <CAFULd4bHpJQau5kw8J93B2Xu1J_tYhShG6eWP88vRvhwxRZmdQ@mail.gmail.com>
2020-10-12 19:33           ` Linus Torvalds
     [not found]             ` <CAFULd4YQ5dNPU5mFuT9GHNH8-UVdcHLz7NYnvPi=kmhaUk1mcw@mail.gmail.com>
2020-10-12 20:57               ` Linus Torvalds
2020-10-13  8:00                 ` Uros Bizjak
2020-10-12 20:27   ` Arvind Sankar
2020-10-13  9:41 ` [GIT PULL -v2] " Borislav Petkov
2020-10-13 20:39   ` Linus Torvalds
2020-10-13 20:47     ` Borislav Petkov
2020-10-13 20:44 ` [GIT PULL] " pr-tracker-bot

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='CAHk-=wgBHgmAoLG9A0b-2_2ZiL_OaXLyO2pbKOHm=u93NttSBQ@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=bp@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=ubizjak@gmail.com \
    --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;
as well as URLs for NNTP newsgroup(s).