From: "Gao, Liming" <liming.gao@intel.com>
To: "Gao, Liming" <liming.gao@intel.com>, Laszlo Ersek <lersek@redhat.com>
Cc: "Justen, Jordan L" <jordan.l.justen@intel.com>,
"edk2-devel@ml01.01.org" <edk2-devel@ml01.01.org>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [Patch 4/4] BaseTools Makefile: Enable Ofast option for GCC tool chain
Date: Fri, 30 Sep 2016 06:56:56 +0000 [thread overview]
Message-ID: <4A89E2EF3DFEDB4C8BFDE51014F606A14B47F136@shsmsx102.ccr.corp.intel.com> (raw)
In-Reply-To: <4A89E2EF3DFEDB4C8BFDE51014F606A14B47EDEF@shsmsx102.ccr.corp.intel.com>
Ersek:
I try O2 option. Compared to Ofast, there is a little different. I think it is acceptable. I will use O2 option. And, this warning message also exists without O2 enable. It is not introduced by this patch.
Tool Compression time Decompression time
LzmaCompress (GCC O0) 3.476s 0.204s
LzmaCompress (GCC Ofast) 1.655s 0.107s
LzmaCompress (GCC O2) 1.687s 0.105s
Thanks
Liming
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Gao, Liming
Sent: Friday, September 30, 2016 8:24 AM
To: Laszlo Ersek <lersek@redhat.com>
Cc: Justen, Jordan L <jordan.l.justen@intel.com>; edk2-devel@ml01.01.org; Ard Biesheuvel <ard.biesheuvel@linaro.org>
Subject: Re: [edk2] [Patch 4/4] BaseTools Makefile: Enable Ofast option for GCC tool chain
Laszlo:
Thanks for your suggestion. I will try O2 option and see the performance and warning.
Thanks
Liming
From: Laszlo Ersek [mailto:lersek@redhat.com]
Sent: Friday, September 30, 2016 2:30 AM
To: Gao, Liming
Cc: edk2-devel@ml01.01.org<mailto:edk2-devel@ml01.01.org>; Ard Biesheuvel ; Justen, Jordan L
Subject: Re: [edk2] [Patch 4/4] BaseTools Makefile: Enable Ofast option for GCC tool chain
Hi Liming,
On 09/29/16 16:12, Liming Gao wrote:
> Enable Ofast option to generate fast code for performance improvement.
>
> Contributed-under: TianoCore Contribution Agreement 1.0
> Signed-off-by: Liming Gao
> ---
> BaseTools/Source/C/Makefiles/header.makefile | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/BaseTools/Source/C/Makefiles/header.makefile b/BaseTools/Source/C/Makefiles/header.makefile
> index f2041f8..ca2dc2e 100644
> --- a/BaseTools/Source/C/Makefiles/header.makefile
> +++ b/BaseTools/Source/C/Makefiles/header.makefile
> @@ -44,12 +44,12 @@ ARCH_INCLUDE = -I $(MAKEROOT)/Include/AArch64/
> endif
>
> INCLUDE = $(TOOL_INCLUDE) -I $(MAKEROOT) -I $(MAKEROOT)/Include/Common -I $(MAKEROOT)/Include/ -I $(MAKEROOT)/Include/IndustryStandard -I $(MAKEROOT)/Common/ -I .. -I . $(ARCH_INCLUDE)
> -BUILD_CPPFLAGS = $(INCLUDE)
> +BUILD_CPPFLAGS = $(INCLUDE) -Ofast
> ifeq ($(DARWIN),Darwin)
> # assume clang or clang compatible flags on OS X
> -BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-self-assign -nostdlib -c -g
> +BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-self-assign -Wno-unused-result -nostdlib -c -g
> else
> -BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -nostdlib -c -g
> +BUILD_CFLAGS = -MD -fshort-wchar -fno-strict-aliasing -Wall -Werror -Wno-deprecated-declarations -Wno-unused-result -nostdlib -c -g
> endif
> BUILD_LFLAGS =
> BUILD_CXXFLAGS =
>
are you sure -Ofast is a good idea? The gcc manual says,
-Ofast
Disregard strict standards compliance. -Ofast enables all -O3
optimizations. It also enables optimizations that are not valid for
all standard-compliant programs. It turns on -ffast-math and the
Fortran-specific -fno-protect-parens and -fstack-arrays.
To me this sounds quite scary -- I'm worried it might break the base
utilities in various obscure ways, which in turn could break the
firmware built with these tools in obscure ways.
Most upstream projects and GNU/Linux distributions use -O2 for
performance-optimized builds. Can you try that please and see if the
performance improvements (relative to the current status) are still
acceptable? If so, I would strongly prefer -O2 over -Ofast.
Also, while building BaseTools with your series applied (using gcc-4.8),
I saw one warning issued:
> g++ -c -I Pccts/h -I .. -I ../Include/Common -I ../Include/ -I ../Include/IndustryStandard -I ../Common/ -I .. -I . -I ../Include/X64/ -Ofast VfrFormPkg.cpp -o VfrFormPkg.o
> VfrFormPkg.cpp: In member function 'void CIfrRecordInfoDB::IfrUpdateRecordInfoForDynamicOpcode(BOOLEAN)':
> VfrFormPkg.cpp:1360:91: warning: deprecated conversion from string constant to 'CHAR8* {aka char*}' [-Wwrite-strings]
> gCVfrErrorHandle.PrintMsg (0, "Error", "Can not find the adjust offset in the record.");
^
Thanks!
Laszlo
_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org<mailto:edk2-devel@lists.01.org>
https://lists.01.org/mailman/listinfo/edk2-devel
next prev parent reply other threads:[~2016-09-30 6:57 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-09-29 14:12 [Patch 0/4] BaseTools: Enable optimization to generate fast code in C tools Liming Gao
2016-09-29 14:12 ` [Patch 1/4] BaseTools EfiLdrImage: Remove unnecessary exit (0) Liming Gao
2016-09-29 14:12 ` [Patch 2/4] BaseTools Makefile: Enable O2 option to replace Od for VS tool chain Liming Gao
2016-09-29 14:12 ` [Patch 3/4] BaseTools GenVtf: Initialize the return point as NULL Liming Gao
2016-09-29 14:12 ` [Patch 4/4] BaseTools Makefile: Enable Ofast option for GCC tool chain Liming Gao
2016-09-29 18:29 ` Laszlo Ersek
2016-09-30 0:24 ` Gao, Liming
2016-09-30 6:56 ` Gao, Liming [this message]
2016-09-30 9:49 ` Laszlo Ersek
2016-09-30 17:46 ` [Patch 0/4] BaseTools: Enable optimization to generate fast code in C tools Jordan Justen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-list from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A89E2EF3DFEDB4C8BFDE51014F606A14B47F136@shsmsx102.ccr.corp.intel.com \
--to=devel@edk2.groups.io \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox