[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YuzowUBt4pTLcMRc@zn.tnic>
Date: Fri, 5 Aug 2022 11:54:09 +0200
From: Borislav Petkov <bp@...en8.de>
To: Kanna Scarlet <knscarlet@...weeb.org>
Cc: Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...hat.com>,
Dave Hansen <dave.hansen@...ux.intel.com>,
"H. Peter Anvin" <hpa@...or.com>, x86@...nel.org,
Ard Biesheuvel <ardb@...nel.org>,
Bill Metzenthen <billm@...bpc.org.au>,
Brijesh Singh <brijesh.singh@....com>,
Joerg Roedel <jroedel@...e.de>,
Josh Poimboeuf <jpoimboe@...nel.org>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Mark Rutland <mark.rutland@....com>,
Michael Roth <michael.roth@....com>,
Peter Zijlstra <peterz@...radead.org>,
Sean Christopherson <seanjc@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Ammar Faizi <ammarfaizi2@...weeb.org>,
GNU/Weeb Mailing List <gwml@...r.gnuweeb.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] x86: Change mov $0, %reg with xor %reg, %reg
On Thu, Aug 04, 2022 at 06:08:05PM +0000, Kanna Scarlet wrote:
> Hello sir Borislav,
Please, no "sir" - just Boris or Borislav,
> Thank you for your response. I tried to find out other advantages of
> xor reg,reg on Google and found this:
> https://stackoverflow.com/a/33668295/7275114
>
> "xor (being a recognized zeroing idiom, unlike mov reg, 0) has some
> obvious and some subtle advantages:
>
> 1. smaller code-size than mov reg,0. (All CPUs)
> 2. avoids partial-register penalties for later code.
> (Intel P6-family and SnB-family).
> 3. doesn't use an execution unit, saving power and freeing up
> execution resources. (Intel SnB-family)
> 4. smaller uop (no immediate data) leaves room in the uop cache-line
> for nearby instructions to borrow if needed. (Intel SnB-family).
> 5. doesn't use up entries in the physical register file. (Intel
> SnB-family (and P4) at least, possibly AMD as well since they use
> a similar PRF design instead of keeping register state in the ROB
> like Intel P6-family microarchitectures.)"
>
> Should I add all in the explanation sir?
You should try to understand what this means and write the gist of it in
your own words. This is how you can learn something.
> We also find more files to patch with this command:
>
> grep -rE "mov.?\s+\\$\\0\s*," arch/x86
>
> it shows many immediate zero moves to 64-bit register in file
> arch/x86/crypto/curve25519-x86_64.c, but the next instruction may depend
> on the previous %rflags value, we are afraid to change this because
> xor touches %rflags. We will try to change it to movl $0, %r32 to
> reduce the code size.
I don't think you need to do that - you can do this one patch in order
to go through the whole process of creating and submitting a patch but
you should not go on a "let's convert everything" spree just for the
sake of it.
Because maintainers barely have time to look at patches, you don't have
to send them more when they're not really needed.
Rather, I'd suggest you go and try to fix real bugs. This has some ideas
what to do:
https://www.linux.com/news/three-ways-beginners-contribute-linux-kernel/
Looking at the kernel bugzilla and trying to understand and reproduce a
bug from there would get you a long way. And you'll learn a lot.
Also, you should peruse
https://www.kernel.org/doc/html/latest/process/index.html
which has a lot of information about how this whole community thing
works.
I sincerely hope that helps.
Thx.
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
Powered by blists - more mailing lists