From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp01.apple.com (ma1-aaemail-dr-lapp01.apple.com [17.171.2.60]) by mx.groups.io with SMTP id smtpd.web12.6686.1584042711215895744 for ; Thu, 12 Mar 2020 12:51:51 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=mTXMC+AZ; spf=pass (domain: apple.com, ip: 17.171.2.60, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp01.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp01.apple.com (8.16.0.27/8.16.0.27) with SMTP id 02CJpmun032205; Thu, 12 Mar 2020 12:51:49 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : content-type : mime-version : subject : from : in-reply-to : date : cc : content-transfer-encoding : message-id : references : to; s=20180706; bh=SsaWoMNx3nCM0lAyH5UOugZYKAiLEeKrWN3xRHRbtNo=; b=mTXMC+AZ/MeVw1jli0C2BRBMtNDha3QOvypKfuJt8v89KgDog+fX7e6qVCCt52GL9m/4 L8EuWAC1BlJlL30t5Lk1ZrK0vZRwekjxeYDnIs4il0Mbv6gx3Bjz1SZEkMrPepentQ9U zlIA3kg5m+0oJGL+7p1/YK3dj7+CqB1mlCsfQdiwkkFZcvmTk9tglStDMyCPFS2ncnYb HRZxy4x299KXEGxpplNBvVDhA2yq9jz7/oDDOVBkjz6dRWkyGrTm32AtFZMwGSCyjRkP zAiedAw8tKaPTiAlI4q9u86kGixIuvksErVoD1IMgJ8n1P9LSv8WM7wscS+HLRABKj3p Pg== Received: from rn-mailsvcp-mta-lapp03.rno.apple.com (rn-mailsvcp-mta-lapp03.rno.apple.com [10.225.203.151]) by ma1-aaemail-dr-lapp01.apple.com with ESMTP id 2yqt83spe5-7 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 12 Mar 2020 12:51:49 -0700 Received: from nwk-mmpp-sz10.apple.com (nwk-mmpp-sz10.apple.com [17.128.115.122]) by rn-mailsvcp-mta-lapp03.rno.apple.com (Oracle Communications Messaging Server 8.1.0.1.20190704 64bit (built Jul 4 2019)) with ESMTPS id <0Q7300WFQJ66B190@rn-mailsvcp-mta-lapp03.rno.apple.com>; Thu, 12 Mar 2020 12:51:42 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz10.apple.com by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0Q7300K00II3QS00@nwk-mmpp-sz10.apple.com>; Thu, 12 Mar 2020 12:51:42 -0700 (PDT) X-Va-A: X-Va-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-Va-E-CD: 832365677e457292e3a122b6def30251 X-Va-R-CD: 4a43ed2b20d7c16b56079406ea304e45 X-Va-CD: 0 X-Va-ID: 5a99ec13-7aae-4b9d-9b94-bf9b12153e50 X-V-A: X-V-T-CD: 07a9f7dd315dc6000695a0402a47d12d X-V-E-CD: 832365677e457292e3a122b6def30251 X-V-R-CD: 4a43ed2b20d7c16b56079406ea304e45 X-V-CD: 0 X-V-ID: 3e50cd53-4d5a-4078-b81d-1160af802c96 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-03-12_13:2020-03-11,2020-03-12 signatures=0 Received: from [17.235.2.193] by nwk-mmpp-sz10.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0Q7300N7RJ641M70@nwk-mmpp-sz10.apple.com>; Thu, 12 Mar 2020 12:51:41 -0700 (PDT) Sender: afish@apple.com MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment From: "Andrew Fish" In-reply-to: Date: Thu, 12 Mar 2020 12:51:40 -0700 Cc: Leif Lindholm , "Schaefer, Daniel (DualStudy)" , "devel@edk2.groups.io" , "Chang, Abner (HPS SW/FW Technologist)" , "Chen, Gilbert" , Mike Kinney , "pete@akeo.ie" , Ard Biesheuvel Message-id: References: <20200302103238.25726-1-daniel.schaefer@hpe.com> <20200302103238.25726-4-daniel.schaefer@hpe.com> <20200312105528.GC23627@bivouac.eciton.net> <539c8673-786c-9c58-98cc-ab470b345740@hpe.com> <20200312140304.GF23627@bivouac.eciton.net> To: Laszlo Ersek X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.138,18.0.572 definitions=2020-03-12_14:2020-03-11,2020-03-12 signatures=0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable > On Mar 12, 2020, at 12:36 PM, Laszlo Ersek wrote: >=20 > On 03/12/20 15:03, Leif Lindholm wrote: >> +Ard, Laszlo. >>=20 >> I think it would make sense to move it to MdeModulePkg (or MdePkg) = and >> rename it BaseCompilerIntrinsicsLib (it *is* a BASE library). >>=20 >> As I alluded in my reply to Ray - x86 also have this problem, but to = a >> lesser extent, and ended up creating library functions to call = instead >> of using plain C for certain operations. >> Which was probably the right decision when it was restricted to a >> very few corner cases. >=20 > I think people that are interested in IA32/X64 are happier with = explicit > CopyMem() calls that are optimized (via one of the several = BaseMemoryLib > instances, such as SSE2, REP + string instructions, MMX, "smart" > (chunked) C code, etc), than with a naive loop, such as the one in > "ArmPkg/Library/CompilerIntrinsicsLib/memcpy.c", that gets silently > plugged into an intrinsic (such as a structure assignment). >=20 > I mean, compiler intrinsics exist in the first place because they > implement language features in a fast / performant manner, behind the > scenes. If we replace the internals of an intrinsic with a slow / = naive > implementation, then the intrinsic has no more right to exist, the > compiler could / should just generate the normal naive code. >=20 > I don't mind the code movement, but I'd like to avoid using > BaseCompilerIntrinsicsLib on IA32/X64. On those arches, I think it = would > only be an improvement if it had a configurable backend, similarly how > CopyMem() is currently configurable. >=20 > ... I guess I've gotten very used to calling CopyMem(), in place of > structure assignment. >=20 Laszlo, My brain has flipped too.=20 For x86 I find smaller structure assignments can cause the optimizer to = optimize away the memcpy/memset and you only see issue issues on a NOOPT = build since DEBUG builds tend to be size optimized. I tend to hit this = issue when I try to turn off optimizations to try and walk vendor code = in the debugger. So code review is the 1st line of defense.=20 Thanks, Andrew Fish