From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-1.mimecast.com (us-smtp-1.mimecast.com [207.211.31.120]) by mx.groups.io with SMTP id smtpd.web12.6332.1584041780930173248 for ; Thu, 12 Mar 2020 12:36:21 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=J2klTo+h; spf=pass (domain: redhat.com, ip: 207.211.31.120, mailfrom: lersek@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584041780; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=jiigtDhdJ7wGjynBXzUrqJK1ciPceQdv6bVXf6fKf3U=; b=J2klTo+hkWpUalky+KT54Av4V2N7mpdaVrLbkuMf19Bb7NrXaL9uVYuvcW4gaQ6CahuilG NZodVKd2EXCgwYkSRaMfKjvCWuxmckLCE7tkJv+F7CiJ4Z2Yqe8TIiHlGt3vWhWR6lqHLy 3xmrRpdq2+xBHuiAmhr5mHKf5QjDScA= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-19-ioNWPUxwO8KY2AKw3nonFg-1; Thu, 12 Mar 2020 15:36:18 -0400 X-MC-Unique: ioNWPUxwO8KY2AKw3nonFg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id C1E75800D48; Thu, 12 Mar 2020 19:36:15 +0000 (UTC) Received: from lacos-laptop-7.usersys.redhat.com (ovpn-117-74.ams2.redhat.com [10.36.117.74]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3E19593513; Thu, 12 Mar 2020 19:36:06 +0000 (UTC) Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment To: Leif Lindholm , "Schaefer, Daniel (DualStudy)" Cc: "devel@edk2.groups.io" , "Chang, Abner (HPS SW/FW Technologist)" , "Chen, Gilbert" , "afish@apple.com" , "michael.d.kinney@intel.com" , "pete@akeo.ie" , Ard Biesheuvel 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> From: "Laszlo Ersek" Message-ID: Date: Thu, 12 Mar 2020 20:36:04 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20200312140304.GF23627@bivouac.eciton.net> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/12/20 15:03, Leif Lindholm wrote: > +Ard, Laszlo. > > I think it would make sense to move it to MdeModulePkg (or MdePkg) and > rename it BaseCompilerIntrinsicsLib (it *is* a BASE library). > > 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. 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). 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. 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. ... I guess I've gotten very used to calling CopyMem(), in place of structure assignment. Thanks Laszlo