public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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


  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