Re: [edk2-devel] [Patch 11/12] OvmfPkg: Enable CLANG9 tool chain -

["Andrew Fish" <afish@apple.com>]

[-- Attachment #1: Type: text/plain, Size: 6376 bytes --]



> 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 = 10;
    float b = 20;

    float c = 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 = mem[0],zero,zero,zero
	movss	LCPI0_1(%rip), %xmm1    ## xmm1 = mem[0],zero,zero,zero
	movl	$0, -4(%rbp)
	movss	%xmm1, -8(%rbp)
	movss	%xmm0, -12(%rbp)
	movss	-8(%rbp), %xmm0         ## xmm0 = 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 = 0x41200000
	movl	$1101004800, -12(%rbp)  ## imm = 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


[-- Attachment #2: Type: text/html, Size: 40843 bytes --]