From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f66.google.com (mail-wr1-f66.google.com [209.85.221.66]) by mx.groups.io with SMTP id smtpd.web11.8064.1584047053348813546 for ; Thu, 12 Mar 2020 14:04:13 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@nuviainc-com.20150623.gappssmtp.com header.s=20150623 header.b=e4gEeu6c; spf=pass (domain: nuviainc.com, ip: 209.85.221.66, mailfrom: leif@nuviainc.com) Received: by mail-wr1-f66.google.com with SMTP id r15so9357020wrx.6 for ; Thu, 12 Mar 2020 14:04:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nuviainc-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=VtlUHIx8zIM4D3/pS4t8c58frfIkgrQFARkD+6kCYko=; b=e4gEeu6cmoJ4hlP5IciAnf7vza+UwQ7vLEa9ZcCL/InViyr62JhsoVEzMCCYhEasgy HZ6JPfiihaYsMZTOGItsNwURJ3O/hej2p9awwf1Y0nC81P/Hkr/+vaHaGU3qOPdr9cqU zwGGqSNiZNGAfJOI2V8nA9QwiS0y9kU43teKw7lRYZQHHeL3fjd20wGzaG78vDA9zqPe nV1Y2TVjG/cHdZWs0skNe8OTjOXRszsgYBrivSfPMqVydWx7isOJWAHiaM6T/OcBbQfR lyk9IvJGcpsddZ282b/KQDxaD5ZjUqaYaKEz7ogYvPpa37yg5N5RgXZKcjS/14UNsYit JUSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=VtlUHIx8zIM4D3/pS4t8c58frfIkgrQFARkD+6kCYko=; b=iepnm3q8svHWU64FZ5nbAxzLjJlN8NPTiKEOIfPxkTaM6uPEh5uPT3EqEs5+MCzAcD rSYm0Z400XwMc5/QKVnjtM4DyYsoodmd/QgFrcn8+utDGOGDL26ckKYdoAvceEVXDvjl YjjLIGttbkZzewe5NE9HoPV+ms0CgJme6N3ZOWYUE7sc7s/Y2eLb7ie0duSW39D7Qvh3 mBU8IQocGjMuK8Qa1e3Fz1JFixcYIRBwyyjdh1Qspi34h6jN93ORRVLOQAXO92bI+t4C L9JjscRMIUSO4KFVugQ36dXwK7AQp6pFjN0R4jdXuiY2+kK5PBNbGm3dJXEgC3glp6dH emcw== X-Gm-Message-State: ANhLgQ1cbx8M2q84dPhOwhUoiP++NbWob55y1YzCJX6rE5Z5wVO7WoSH 5eo8PmZIXEwRYQgZFAu8aWWYWSQPGmC3xFXAzB6WSg1NLic61Ko6w+1fGqQp4SQAzWbjUAS7mFI Q1yNGq2v7U/MRq8N/wItH2ytsg/7Np78x65Eesyt4Udsc4VKqmFYtQSXHlD84+qI= X-Google-Smtp-Source: ADFU+vtbh3FrXKqzFGQ6eH+Sy3ZPa307r4JRdJN6WjfDs/vicBc7g/tTBliIUvek1khTPIXklFV//g== X-Received: by 2002:adf:806c:: with SMTP id 99mr12685173wrk.78.1584047051657; Thu, 12 Mar 2020 14:04:11 -0700 (PDT) Return-Path: Received: from bivouac.eciton.net (bivouac.eciton.net. [2a00:1098:0:86:1000:23:0:2]) by smtp.gmail.com with ESMTPSA id e1sm65691147wrx.90.2020.03.12.14.04.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Mar 2020 14:04:11 -0700 (PDT) Date: Thu, 12 Mar 2020 21:04:09 +0000 From: "Leif Lindholm" To: devel@edk2.groups.io, lersek@redhat.com Cc: "Schaefer, Daniel (DualStudy)" , "Chang, Abner (HPS SW/FW Technologist)" , "Chen, Gilbert" , "afish@apple.com" , "michael.d.kinney@intel.com" , "pete@akeo.ie" , Ard Biesheuvel Subject: Re: [edk2-devel] [PATCH v2 3/3] MdeModulePkg: Use CopyMem instead of GUID assignment Message-ID: <20200312210408.GK23627@bivouac.eciton.net> 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> MIME-Version: 1.0 In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Thu, Mar 12, 2020 at 20:36:04 +0100, Laszlo Ersek wrote: > 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. That may have been the original intent. The end result is we *have* them, so we must do something about them. > 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. Sure. That's a toolchain issue, which we don't always control. In the case of CopyGuid() I would take some convincing that there was a significant difference in performance across 16 bytes of cached memory, performed occasionally. But, if there was, we could do --- a/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf +++ b/ArmPkg/Library/CompilerIntrinsicsLib/CompilerIntrinsicsLib.inf @@ -86,3 +86,4 @@ [Packages] [BuildOptions] MSFT:*_*_*_CC_FLAGS = /GL- MSFT:*_*_ARM_ASM_FLAGS = /oldit + GCC:RELEASE_*_*_CC_FLAGS = -O3 and let idiom recognition take care of inserting the optimised versions in place of the naive ones. > 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. With less than making CompilerIntrinsicLib *not* a BASE library (urgh), we can't have *it* depending on platform-specific optimised versions. The comment about IA32/X64 was more about the few instances we've seen where new code has broken them due to things like dividing 64-bit values withouy function calls, and how in the future it might make sense catching that in other ways. > ... I guess I've gotten very used to calling CopyMem(), in place of > structure assignment. Basically, I don't think having to learn a new dialect of C is consistent with lowering the barrier of entry to the project. Regards, Leif