From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on gnuweeb.org X-Spam-Level: X-Spam-Status: No, score=0.2 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, SPF_HELO_NONE,T_SPF_TEMPERROR,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.6 Received: from mail.skyhub.de (mail.skyhub.de [5.9.137.197]) by gnuweeb.org (Postfix) with ESMTPS id 604878060F for ; Fri, 5 Aug 2022 09:54:24 +0000 (UTC) Authentication-Results: gnuweeb.org; dkim=pass (1024-bit key; unprotected) header.d=alien8.de header.i=@alien8.de header.a=rsa-sha256 header.s=dkim header.b=eHl+Jkod; dkim-atps=neutral Received: from zn.tnic (p200300ea971b986e329c23fffea6a903.dip0.t-ipconnect.de [IPv6:2003:ea:971b:986e:329c:23ff:fea6:a903]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.skyhub.de (SuperMail on ZX Spectrum 128k) with ESMTPSA id 673001EC026E; Fri, 5 Aug 2022 11:54:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alien8.de; s=dkim; t=1659693254; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:in-reply-to:in-reply-to: references:references; bh=tIfI1N0OONraULlSScaWCqIMJV2l+ByDvpkRGd3vG54=; b=eHl+JkodlgJQbZ2VLjg9LAOurlfEyzlBSTD9IUQWef3IoIobqpsgAeajCjP90mIZT42oOf VXNNB5jmdzl6HIPL60bf/lO1r6EM8VcsIbHGhm4LTRogwDB+Rh3unSxm4O7gU6xa9eJHjs 8TewOGVhZhxc5+lJ4dl1S8TF9P9f5YQ= Date: Fri, 5 Aug 2022 11:54:09 +0200 From: Borislav Petkov To: Kanna Scarlet Cc: Thomas Gleixner , Ingo Molnar , Dave Hansen , "H. Peter Anvin" , x86@kernel.org, Ard Biesheuvel , Bill Metzenthen , Brijesh Singh , Joerg Roedel , Josh Poimboeuf , "Kirill A. Shutemov" , Mark Rutland , Michael Roth , Peter Zijlstra , Sean Christopherson , Steven Rostedt , Ammar Faizi , GNU/Weeb Mailing List , Linux Kernel Mailing List Subject: Re: [PATCH 1/1] x86: Change mov $0, %reg with xor %reg, %reg Message-ID: References: <20220804152656.8840-1-knscarlet@gnuweeb.org> <20220804152656.8840-2-knscarlet@gnuweeb.org> <20220804180805.9077-1-knscarlet@gnuweeb.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20220804180805.9077-1-knscarlet@gnuweeb.org> List-Id: 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