From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from ma1-aaemail-dr-lapp02.apple.com (ma1-aaemail-dr-lapp02.apple.com [17.171.2.68]) by mx.groups.io with SMTP id smtpd.web11.6762.1570638170138328588 for ; Wed, 09 Oct 2019 09:22:50 -0700 Authentication-Results: mx.groups.io; dkim=pass header.i=@apple.com header.s=20180706 header.b=S64g6BTI; spf=pass (domain: apple.com, ip: 17.171.2.68, mailfrom: afish@apple.com) Received: from pps.filterd (ma1-aaemail-dr-lapp02.apple.com [127.0.0.1]) by ma1-aaemail-dr-lapp02.apple.com (8.16.0.27/8.16.0.27) with SMTP id x99GM5fd008173; Wed, 9 Oct 2019 09:22:48 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=apple.com; h=sender : from : message-id : content-type : mime-version : subject : date : in-reply-to : cc : to : references; s=20180706; bh=x9080C5W/s9fhxHIbOOQi+6Dh2mKsdKSCmF9vDn9kG0=; b=S64g6BTIAOJXIJd6JV6iaJ8UU9Swb/ecQbPzHhWefKJK6aMhKbg0LncDFErcbnEUW41U mXQ2E+0EApJ+AZHLcJzryTZqT70+hmKXHX4lfXTDGGkj9J+9lCvIJG/IA5fjy8hzvGf1 pMDJHKkXCfQ+wi4JZNu7/+H2GaiQSmQJArqFbysfXpqsiyzYgDUFwY2bQjS03nfRmnUK QFXZnfN+YhAbf6YGB48L47vyzKVQbpagcACmVx4YyaQWyvDwgGLrX0ANOLKVPoH9YDdR z4qgI3tw3nrfPQc+4sKzZTWHThFV3D6t423Hg4NPbl1mYFPDZgYNd+ELiIu7MSxpvVUi 3Q== Received: from ma1-mtap-s01.corp.apple.com (ma1-mtap-s01.corp.apple.com [17.40.76.5]) by ma1-aaemail-dr-lapp02.apple.com with ESMTP id 2vequvcr9m-17 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 09 Oct 2019 09:22:48 -0700 Received: from nwk-mmpp-sz13.apple.com (nwk-mmpp-sz13.apple.com [17.128.115.216]) by ma1-mtap-s01.corp.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPS id <0PZ400AC285XGW50@ma1-mtap-s01.corp.apple.com>; Wed, 09 Oct 2019 09:22:45 -0700 (PDT) Received: from process_milters-daemon.nwk-mmpp-sz13.apple.com by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) id <0PZ400F0084PGV00@nwk-mmpp-sz13.apple.com>; Wed, 09 Oct 2019 09:22:45 -0700 (PDT) X-Va-A: X-Va-T-CD: 281f8fa03638b888ab0035439e9fe9bb X-Va-E-CD: 326cdb6df90800fe24dea31ce30968ce X-Va-R-CD: efbf3b14fd5df68a90616b0c895917e0 X-Va-CD: 0 X-Va-ID: 478164d0-1634-4325-91f7-a52e0565bb11 X-V-A: X-V-T-CD: 281f8fa03638b888ab0035439e9fe9bb X-V-E-CD: 326cdb6df90800fe24dea31ce30968ce X-V-R-CD: efbf3b14fd5df68a90616b0c895917e0 X-V-CD: 0 X-V-ID: 9ceb4204-bcf8-4a1d-ba59-301d72f4c33f X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-09_07:,, signatures=0 Received: from [17.235.15.166] (unknown [17.235.15.166]) by nwk-mmpp-sz13.apple.com (Oracle Communications Messaging Server 8.0.2.4.20190507 64bit (built May 7 2019)) with ESMTPSA id <0PZ400BJ285V5W50@nwk-mmpp-sz13.apple.com>; Wed, 09 Oct 2019 09:22:44 -0700 (PDT) Sender: afish@apple.com From: "Andrew Fish" Message-id: MIME-version: 1.0 (Mac OS X Mail 13.0 \(3594.4.17\)) Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain - Date: Wed, 09 Oct 2019 09:22:43 -0700 In-reply-to: <4A89E2EF3DFEDB4C8BFDE51014F606A14E514EAB@SHSMSX104.ccr.corp.intel.com> Cc: Laszlo Ersek , "devel@edk2.groups.io" To: "Gao, Liming" References: <1569570395-11240-1-git-send-email-liming.gao@intel.com> <1569570395-11240-12-git-send-email-liming.gao@intel.com> <4c27bdc4-60b4-26bf-c416-c02b69ef8051@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E5124FA@SHSMSX104.ccr.corp.intel.com> <7fc791fe-9d08-9763-ecc9-529e88b621c6@redhat.com> <767711D5-7C33-4703-8E97-F4F5B5A6BD5F@apple.com> <6f49899d-b5e4-70ad-82e5-08c5a8649ac8@redhat.com> <4A89E2EF3DFEDB4C8BFDE51014F606A14E514EAB@SHSMSX104.ccr.corp.intel.com> X-Mailer: Apple Mail (2.3594.4.17) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:,, definitions=2019-10-09_07:,, signatures=0 Content-type: multipart/alternative; boundary="Apple-Mail=_E414E31C-3276-4420-B4C3-09B4E9E75F27" --Apple-Mail=_E414E31C-3276-4420-B4C3-09B4E9E75F27 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Oct 9, 2019, at 7:44 AM, Gao, Liming wrote: >=20 > Laszlo: >=20 >> -----Original Message----- >> From: Laszlo Ersek >> Sent: Wednesday, October 9, 2019 9:44 PM >> To: Andrew Fish ; devel@edk2.groups.io >> Cc: Gao, Liming >> Subject: Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool = chain >>=20 >> On 10/09/19 01:08, Andrew Fish wrote: >>=20 >>> So I guess the way to describe it is XCODE inherits GCC and only = needs to override when it is different. >>=20 >> Thank you for the explanation! >>=20 >> I've been trying to figure out why this inheritance bothers me so = much. >> I guess the reason is the following: >>=20 >> I'm a user of the actual GCCxx toolchains (such as GCC48, GCC49, = GCC5). >> Assume that I realize that a gcc-specific change is needed to some = part >> of the code. (It could be build options, or gcc specific source code, >> etc.) Then, I go to the gcc documentation, and verify whether the = change >> is indeed supported by all the relevant gcc versions. >>=20 >> If the change is possible with only some gcc versions, then I likely >> write the change for a specific toolchain only, such as GCC5. Fine. >>=20 >> Now assume that my documentation review proves that *all* GCCxx >> toolchains, supported by edk2, should receive the update. This could = be >> a #pragma, a command line flag, some __attribute__, etc. I'd very = likely >> express the change for the whole GCC toolchain *family*, and not >> enumerate it for GCC48, GCC49, GCC5 individually. >>=20 >> And now I learn that said approach would be wrong, because such a = change >> would be inherited by XCODExx and CLANGxx too (via FAMILY), fully >> against my intent, unless XCODExx and CLANGxx overrode the particular >> aspect (via BUILDRULEFAMILY). >=20 > The difference between XCODE/CLANG and GCCXX is the linker. Current = patches are > introduced for the different linker. Clang supports most usage of GCC = compiler. > So, CLANG and XCODE uses GCC family. When I enable XCODE or CLANG tool = chain > in the platform, I don't find other incompatible behavior with GCC = compiler. > So, I think it is safe to let CLANG inherit GCC option except for = these two cases. > When you make new changes, and verify them with GCC compiler, that's = enough. > You don't need to specially verify them with XCODE or CLANG. In most = case, GCC=20 > compiler pass, XCODE or CLANG can also pass. >=20 Liming, I agree that clang attempts to be drop in compatible with GCC and the = big difference is the linker. For the most part XCODE means macOS linker = + clang.=20 I thought the thing we were discussing was compiler flags. Specifically = -mno-mmx -mno-sse. It seems to me if OVMF requires -mno-mmx -mno-sse = then it is a bug in the tools_def.txt definition for those compilers? = As far as I can tell -mno-implicit-float should prevent the optimizer = from using floating point. The -mno-mmx -mno-sse flags most change how = floating point code gets compiled [1]. it looks like -mno-mmx -mno-sse = just down grade floating point instructions that get used. Thus it seems = like either we have some code doing float and that code should set = -mno-mmx -mno-sse, or the -mno-mmx -mno-sse should be set generically.=20= [1] ~/work/Compiler/float>cat c.c int main() { float a =3D 10; float b =3D 20; float c =3D a * b; return 0; } ~/work/Compiler/float>clang -S c.c -mno-implicit-float ~/work/Compiler/float>cat c.S .section __TEXT,__text,regular,pure_instructions .build_version macos, 10, 15 sdk_version 10, 15 .section __TEXT,__literal4,4byte_literals .p2align 2 ## -- Begin function main LCPI0_0: .long 1101004800 ## float 20 LCPI0_1: .long 1092616192 ## float 10 .section __TEXT,__text,regular,pure_instructions .globl _main .p2align 4, 0x90 _main: ## @main .cfi_startproc ## %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp xorl %eax, %eax movss LCPI0_0(%rip), %xmm0 ## xmm0 =3D = mem[0],zero,zero,zero movss LCPI0_1(%rip), %xmm1 ## xmm1 =3D = mem[0],zero,zero,zero movl $0, -4(%rbp) movss %xmm1, -8(%rbp) movss %xmm0, -12(%rbp) movss -8(%rbp), %xmm0 ## xmm0 =3D = mem[0],zero,zero,zero mulss -12(%rbp), %xmm0 movss %xmm0, -16(%rbp) popq %rbp retq .cfi_endproc ## -- End function .subsections_via_symbols ~/work/Compiler/float>clang -S c.c -mno-implicit-float -mno-mmx -mno-sse ~/work/Compiler/float>cat c.S .section __TEXT,__text,regular,pure_instructions .build_version macos, 10, 15 sdk_version 10, 15 .globl _main ## -- Begin function main .p2align 4, 0x90 _main: ## @main .cfi_startproc ## %bb.0: pushq %rbp .cfi_def_cfa_offset 16 .cfi_offset %rbp, -16 movq %rsp, %rbp .cfi_def_cfa_register %rbp xorl %eax, %eax movl $0, -4(%rbp) movl $1092616192, -8(%rbp) ## imm =3D 0x41200000 movl $1101004800, -12(%rbp) ## imm =3D 0x41A00000 flds -8(%rbp) flds -12(%rbp) fmulp %st(1) fstps -16(%rbp) popq %rbp retq .cfi_endproc ## -- End function .subsections_via_symbols ~/work/Compiler/float> Thanks, Andrew Fish > Thanks > Liming >>=20 >> This means that, after checking the gcc documentation meticulously >> (multiple releases), and possibly even testing multiple gcc >> installations, I could still regress edk2 (CLANGxx and/or XCODExx >> specific parts), because they could inherit my GCC-oriented changes = that >> I never meant for CLANGxx and/or XCODExx. >>=20 >> I don't use XCODE or CLANG, I don't test on them, and now it seems I = can >> restrict changes to the *actual* gcc compilers only if I keep = spelling >> out the individual toolchain names, such as GCC48, GCC49, GCC5. >>=20 >> This makes the toolchain family concept totally useless to me (and to >> other users that only care about actual gcc compilers). There is no >> *family* facility available that allows people to restrict settings = to >> actual gcc compilers. In other words, we can't express "all GCCxx >> toolchains, regardless of toolchain version, but not XCODE, and also = not >> CLANG". >>=20 >> Thanks >> Laszlo --Apple-Mail=_E414E31C-3276-4420-B4C3-09B4E9E75F27 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

On Oct 9, 2019, at 7:44 AM, Gao, Liming <liming.gao@intel.com> wrote:

Laszlo:

-----Original Message-----
From: Laszlo Ersek = <lersek@redhat.com>
Sent: Wednesday, = October 9, 2019 9:44 PM
To: Andrew Fish <afish@apple.com>; devel@edk2.groups.io
Cc: Gao, Liming <liming.gao@intel.com>
Subject: Re: = [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain

On 10/09/19 01:08, Andrew Fish wrote:

So I = guess the way to describe it is XCODE inherits GCC and only needs to = override when it is different.

Thank you for the explanation!

I've been trying to figure out why this inheritance bothers = me so much.
I guess the reason is the following:

I'm a user of the actual GCCxx toolchains = (such as GCC48, GCC49, GCC5).
Assume that I realize that a = gcc-specific change is needed to some part
of the code. = (It could be build options, or gcc specific source code,
etc.) Then, I go to the gcc documentation, and verify whether = the change
is indeed supported by all the relevant gcc = versions.

If the change is possible with = only some gcc versions, then I likely
write the change for = a specific toolchain only, such as GCC5. Fine.

Now assume that my documentation review proves that *all* = GCCxx
toolchains, supported by edk2, should receive the = update. This could be
a #pragma, a command line flag, some = __attribute__, etc. I'd very likely
express the change for = the whole GCC toolchain *family*, and not
enumerate it for = GCC48, GCC49, GCC5 individually.

And now I = learn that said approach would be wrong, because such a change
would be inherited by XCODExx and CLANGxx too (via FAMILY), = fully
against my intent, unless XCODExx and CLANGxx = overrode the particular
aspect (via BUILDRULEFAMILY).

The difference between XCODE/CLANG and GCCXX is the linker. = Current patches are
introduced for the different linker. Clang supports most = usage of GCC compiler.
So, CLANG and XCODE uses GCC family. When I enable XCODE or = CLANG tool chain
in the platform, I don't find other incompatible behavior = with GCC compiler.
So, I think it is safe to let CLANG inherit GCC option except = for these two cases.
When you make new changes, and verify them with GCC compiler, = that's enough.
You don't need to specially verify them with XCODE or CLANG. = In most case, GCC 
compiler pass, XCODE or CLANG = can also pass.


Liming,

I = agree that clang attempts to be drop in compatible with GCC and the big = difference is the linker. For the most part XCODE means macOS linker + = clang. 

I thought the thing we = were discussing was compiler flags. Specifically -mno-mmx -mno-sse. It = seems to me if OVMF requires -mno-mmx -mno-sse then it is a bug in the = tools_def.txt definition for those compilers?  As far as I can = tell -mno-implicit-float should prevent the optimizer from using = floating point. The -mno-mmx -mno-sse flags most change how floating = point code gets compiled [1]. it looks like -mno-mmx -mno-sse just down = grade floating point instructions that get used. Thus it seems like = either we have some code doing float and that code should set -mno-mmx = -mno-sse, or the -mno-mmx -mno-sse should be set = generically. 

[1]
~/work/Compiler/float>cat c.c
int main()
{
    float a =3D = 10;
    float b =3D = 20;

  =   float c =3D a * b;

  =   return 0;
}
~/work/Compiler/float>clang -S c.c = -mno-implicit-float
~/work/Compiler/float>cat c.S
= .section = __TEXT,__text,regular,pure_instructions
= .build_version macos, 10, 15 sdk_version 10, = 15
.section = __TEXT,__literal4,4byte_literals
= .p2align = 2               ## -- Begin = function main
LCPI0_0:
= .long = 1101004800              ## = float 20
LCPI0_1:
= .long = 1092616192              ## = float 10
.section = __TEXT,__text,regular,pure_instructions
= .globl = _main
.p2align 4, = 0x90
_main:          =                     =     ## @main
= .cfi_startproc
## = %bb.0:
pushq %rbp
= .cfi_def_cfa_offset 16
= .cfi_offset %rbp, -16
movq %rsp, = %rbp
.cfi_def_cfa_register = %rbp
xorl %eax, %eax
= movss = LCPI0_0(%rip), %xmm0    ## xmm0 =3D = mem[0],zero,zero,zero
= movss = LCPI0_1(%rip), %xmm1    ## xmm1 =3D = mem[0],zero,zero,zero
movl $0, = -4(%rbp)
movss %xmm1, -8(%rbp)
= movss = %xmm0, -12(%rbp)
= movss = -8(%rbp), %xmm0         ## xmm0 =3D = mem[0],zero,zero,zero
= mulss = -12(%rbp), %xmm0
= movss = %xmm0, -16(%rbp)
popq = %rbp
retq
= .cfi_endproc
          =                     =           ## -- End function

.subsections_via_symbols
~/work/Compiler/float>clang -S c.c -mno-implicit-float = -mno-mmx -mno-sse
~/work/Compiler/float>cat c.S
= .section = __TEXT,__text,regular,pure_instructions
= .build_version macos, 10, 15 sdk_version 10, = 15
.globl _main =                   ## -- = Begin function main
.p2align 4, = 0x90
_main:          =                     =     ## @main
= .cfi_startproc
## = %bb.0:
pushq %rbp
= .cfi_def_cfa_offset 16
= .cfi_offset %rbp, -16
movq %rsp, = %rbp
.cfi_def_cfa_register = %rbp
xorl %eax, %eax
= movl = $0, -4(%rbp)
movl $1092616192, -8(%rbp)   ## = imm =3D 0x41200000
movl $1101004800, -12(%rbp)  ## = imm =3D 0x41A00000
flds -8(%rbp)
= flds = -12(%rbp)
fmulp %st(1)
= fstps = -16(%rbp)
popq %rbp
= retq
.cfi_endproc
                =                     =     ## -- End function

.subsections_via_symbols
~/work/Compiler/float>

Thanks,

Andrew Fish

Thanks
Liming

This means that, after = checking the gcc documentation meticulously
(multiple = releases), and possibly even testing multiple gcc
installations, I could still regress edk2 (CLANGxx and/or = XCODExx
specific parts), because they could inherit my = GCC-oriented changes that
I never meant for CLANGxx and/or = XCODExx.

I don't use XCODE or CLANG, I = don't test on them, and now it seems I can
restrict = changes to the *actual* gcc compilers only if I keep spelling
out the individual toolchain names, such as GCC48, GCC49, = GCC5.

This makes the toolchain family = concept totally useless to me (and to
other users that = only care about actual gcc compilers). There is no
*family* = facility available that allows people to restrict settings to
actual gcc compilers. In other words, we can't express "all = GCCxx
toolchains, regardless of toolchain version, but not = XCODE, and also not
CLANG".

Thanks
Laszlo

= --Apple-Mail=_E414E31C-3276-4420-B4C3-09B4E9E75F27--