Thoughts about introducing OPTIMIZATION_CFLAG

Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

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

[ Not sure if I have addressed all the correct people and mailing-lists ]

Hi,

while still digging into a llvmlinux issue with workqueue I saw that
the wrong optimization compiler-flag was used on x86 architecture and
acpi subsystem.

CLANG requires '-Oz' whereas GCC requires '-Os'.

As acpi-daemon was throwing out the regression I looked by accident
over the *_CFLAGS.
As said... I checked only for x86 and acpi only.

For example '-Os' is hardcoded in...

arch/x86/Makefile
arch/x86/purgatory/Makefile

drivers/acpi/Makefile
drivers/acpi/acpica/Makefile

For acpi part we have currently both used '-O2' and '-Os' ('-Oz' for
llvmlinux) in approx 200 make-lines.

$ grep '\-O2' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi | wc -l
226
$ grep '\-Oz' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi |
grep '\-O2' | wc -l
200

So, which optimization-cflags is now used if I have both in one
make-line (and how can I check this)?

[ EXAMPLE ]

$ mycompiler --version
clang version 3.7.0 (tags/RELEASE_370/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$  mycompiler -Wp,-MD,drivers/acpi/.video_detect.o.d  -nostdinc
-isystem /opt/llvm-toolchain-3.7.0/bin/../lib/clang/3.7.0/include
-nostdinc -isystem
/opt/llvm-toolchain-3.7.0/bin/../lib/clang/3.7.0/include
-I./arch/x86/include -Iarch/x86/include/generated/uapi
-Iarch/x86/include/generated  -Iinclude -I./arch/x86/include/uapi
-Iarch/x86/include/generated/uapi -I./include/uapi
-Iinclude/generated/uapi -include ./include/linux/kconfig.h
-D__KERNEL__ -Qunused-arguments -Wno-unknown-warning-option -Wall
-Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security
-std=gnu89 -no-integrated-as -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
-mno-avx -m64 -mtune=generic -mno-red-zone -mcmodel=kernel
-funit-at-a-time -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
-DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
-DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare
-fno-asynchronous-unwind-tables *** -O2 *** -Wframe-larger-than=1024
-fno-stack-protector -Wno-unused-variable
-Wno-format-invalid-specifier -Wno-gnu -Wno-asm-operand-widths
-Wno-initializer-overrides -fno-builtin -Wno-tautological-compare
-mno-global-merge -fno-omit-frame-pointer -fno-optimize-sibling-calls
-pg -Wdeclaration-after-statement -Wno-pointer-sign
-fno-strict-overflow -Werror=implicit-int -Werror=strict-prototypes
-Werror=date-time -Wno-initializer-overrides -Wno-unused-value
-Wno-format -Wno-unknown-warning-option -Wno-sign-compare
-Wno-format-zero-length -Wno-uninitialized *** -Oz *** -DMODULE
-D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(video_detect)"
-D"KBUILD_MODNAME=KBUILD_STR(video)" -c -o
drivers/acpi/.tmp_video_detect.o drivers/acpi/video_detect.c

How can I switch a optimization-cflags for certain code-parts in the
Linux-kernel (with or without the kbuild-system)?
( So the default optimization-cflags is '-O2' whereas parts wants '-Os'. )

What to do when using CONFIG_CC_OPTIMIZE_FOR_SIZE=y which sets '-Os' explicitly?

Below tools/ directory we have also an OPTIMIZATION variable used.

Something like a "global" solution is desired from my side.

I have attached a patchset on top of my llvmlinux-amd64-fixes-4.4,
hope this helps a bit to see what I mean.
It is not doing what I desire - still WIP.

Thoughts?

Thanks in advance.

Regards,
- Sedat -

[-- Attachment #2: 0001-kbuild-Introduce-OPTIMIZATION_CFLAGS.patch --]
[-- Type: text/x-diff, Size: 1640 bytes --]

From ed66e809d779d0ce5db6b71ad48792010bf6aad3 Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Mon, 4 Jan 2016 11:16:00 +0100
Subject: [PATCH 1/3] kbuild: Introduce OPTIMIZATION_CFLAGS

Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
 Makefile | 11 ++++++-----
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/Makefile b/Makefile
index dcdb24b27dde..30cd406a4475 100644
--- a/Makefile
+++ b/Makefile
@@ -295,10 +295,12 @@ CONFIG_SHELL := $(shell if [ -x "$$BASH" ]; then echo $$BASH; \
 	  else if [ -x /bin/bash ]; then echo /bin/bash; \
 	  else echo sh; fi ; fi)
 
+OPTIMIZATION_CFLAGS := -O2
+
 HOSTCC       = gcc
 HOSTCXX      = g++
-HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 -fomit-frame-pointer -std=gnu89
-HOSTCXXFLAGS = -O2
+HOSTCFLAGS   = -Wall -Wmissing-prototypes -Wstrict-prototypes $(OPTIMIZATION_CFLAGS) -fomit-frame-pointer -std=gnu89
+HOSTCXXFLAGS = $(OPTIMIZATION_CFLAGS)
 
 HOSTCFLAGS  += -Wno-unused-value -Wno-unused-parameter -Wno-missing-field-initializers
 ifneq ($(shell $(HOSTCC) -v 2>&1 | grep -c "clang version"), 1)
@@ -623,11 +625,10 @@ KBUILD_CFLAGS	+= $(call cc-option,-fno-delete-null-pointer-checks,)
 endif
 
 ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
-KBUILD_CFLAGS 	+= $(call cc-option,-Oz,-Os)
+OPTIMIZATION_CFLAGS := $(call cc-option,-Oz,-Os)
 KBUILD_CFLAGS	+= $(call cc-disable-warning,maybe-uninitialized,)
-else
-KBUILD_CFLAGS	+= -O2
 endif
+KBUILD_CFLAGS	+= $(OPTIMIZATION_CFLAGS)
 
 # Tell gcc to never replace conditional load with a non-conditional one
 KBUILD_CFLAGS	+= $(call cc-option,--param=allow-store-data-races=0)
-- 
2.6.4


[-- Attachment #3: 0002-x86-llvmlinux-Use-OPTIMIZATION_CFLAGS.patch --]
[-- Type: text/x-diff, Size: 1844 bytes --]

From a1224cbda2227a10cc86bc7b1c0442df7015f26c Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Mon, 4 Jan 2016 11:41:51 +0100
Subject: [PATCH 2/3] x86: llvmlinux: Use OPTIMIZATION_CFLAGS

Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
 arch/x86/Makefile           | 4 +++-
 arch/x86/purgatory/Makefile | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index 5fa41ffe15e2..a88d0d490191 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -20,7 +20,9 @@ endif
 CODE16GCC_CFLAGS := -m32 -Wa,$(srctree)/arch/x86/boot/code16gcc.h
 M16_CFLAGS	 := $(call cc-option, -m16, $(CODE16GCC_CFLAGS))
 
-REALMODE_CFLAGS	:= $(M16_CFLAGS) -g -Os -D__KERNEL__ \
+OPTIMIZATION_CFLAGS := $(call cc-option,-Oz,-Os)
+
+REALMODE_CFLAGS	:= $(M16_CFLAGS) -g $(OPTIMIZATION_CFLAGS) -D__KERNEL__ \
 		   -DDISABLE_BRANCH_PROFILING \
 		   -Wall -Wstrict-prototypes -march=i386 -mregparm=3 \
 		   -fno-strict-aliasing -fomit-frame-pointer -fno-pic \
diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile
index 2c835e356349..c9ffc07f9fa3 100644
--- a/arch/x86/purgatory/Makefile
+++ b/arch/x86/purgatory/Makefile
@@ -10,7 +10,9 @@ targets += purgatory.ro
 # in turn leaves some undefined symbols like __fentry__ in purgatory and not
 # sure how to relocate those. Like kexec-tools, use custom flags.
 
-KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -MD -Os -mcmodel=large
+OPTIMIZATION_CFLAGS := $(call cc-option,-Oz,-Os)
+
+KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -MD $(OPTIMIZATION_CFLAGS) -mcmodel=large
 KBUILD_CFLAGS += -m$(BITS)
 
 $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE
-- 
2.6.4


[-- Attachment #4: 0003-acpi-llvmlinux-Use-OPTIMIZATION_CFLAGS.patch --]
[-- Type: text/x-diff, Size: 1312 bytes --]

From 3ed0fdeafd219518ceff601cbb4df562c09374da Mon Sep 17 00:00:00 2001
From: Sedat Dilek <sedat.dilek@gmail.com>
Date: Mon, 4 Jan 2016 11:42:58 +0100
Subject: [PATCH 3/3] acpi: llvmlinux: Use OPTIMIZATION_CFLAGS

Signed-off-by: Sedat Dilek <sedat.dilek@gmail.com>
---
 drivers/acpi/Makefile        | 4 +++-
 drivers/acpi/acpica/Makefile | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 675eaf337178..8a52558da32d 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -2,7 +2,9 @@
 # Makefile for the Linux ACPI interpreter
 #
 
-ccflags-y			:= -Os
+OPTIMIZATION_CFLAGS 		:= $(call cc-option,-Oz,-Os)
+
+ccflags-y			:= $(OPTIMIZATION_CFLAGS)
 ccflags-$(CONFIG_ACPI_DEBUG)	+= -DACPI_DEBUG_OUTPUT
 
 #
diff --git a/drivers/acpi/acpica/Makefile b/drivers/acpi/acpica/Makefile
index 885936f79542..44b4648ccb46 100644
--- a/drivers/acpi/acpica/Makefile
+++ b/drivers/acpi/acpica/Makefile
@@ -2,7 +2,9 @@
 # Makefile for ACPICA Core interpreter
 #
 
-ccflags-y			:= -Os -DBUILDING_ACPICA
+OPTIMIZATION_CFLAGS		:= $(call cc-option,-Oz,-Os)
+
+ccflags-y			:= $(OPTIMIZATION_CFLAGS) -DBUILDING_ACPICA
 ccflags-$(CONFIG_ACPI_DEBUG)	+= -DACPI_DEBUG_OUTPUT
 
 # use acpi.o to put all files here into acpi.o modparam namespace
-- 
2.6.4

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

On Mon, Jan 4, 2016 at 11:54 AM, Sedat Dilek <sedat.dilek@gmail.com> wrote:
> [ Not sure if I have addressed all the correct people and mailing-lists ]
>
> Hi,
>
> while still digging into a llvmlinux issue with workqueue I saw that
> the wrong optimization compiler-flag was used on x86 architecture and
> acpi subsystem.
>
> CLANG requires '-Oz' whereas GCC requires '-Os'.
>
> As acpi-daemon was throwing out the regression I looked by accident
> over the *_CFLAGS.
> As said... I checked only for x86 and acpi only.
>
> For example '-Os' is hardcoded in...
>
> arch/x86/Makefile
> arch/x86/purgatory/Makefile
>
> drivers/acpi/Makefile
> drivers/acpi/acpica/Makefile
>
> For acpi part we have currently both used '-O2' and '-Os' ('-Oz' for
> llvmlinux) in approx 200 make-lines.
>
> $ grep '\-O2' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi | wc -l
> 226
> $ grep '\-Oz' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi |
> grep '\-O2' | wc -l
> 200
>
> So, which optimization-cflags is now used if I have both in one
> make-line (and how can I check this)?
>
> [ EXAMPLE ]
>
> $ mycompiler --version
> clang version 3.7.0 (tags/RELEASE_370/final)
> Target: x86_64-unknown-linux-gnu
> Thread model: posix
>
> $  mycompiler -Wp,-MD,drivers/acpi/.video_detect.o.d  -nostdinc
> -isystem /opt/llvm-toolchain-3.7.0/bin/../lib/clang/3.7.0/include
> -nostdinc -isystem
> /opt/llvm-toolchain-3.7.0/bin/../lib/clang/3.7.0/include
> -I./arch/x86/include -Iarch/x86/include/generated/uapi
> -Iarch/x86/include/generated  -Iinclude -I./arch/x86/include/uapi
> -Iarch/x86/include/generated/uapi -I./include/uapi
> -Iinclude/generated/uapi -include ./include/linux/kconfig.h
> -D__KERNEL__ -Qunused-arguments -Wno-unknown-warning-option -Wall
> -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing
> -fno-common -Werror-implicit-function-declaration -Wno-format-security
> -std=gnu89 -no-integrated-as -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
> -mno-avx -m64 -mtune=generic -mno-red-zone -mcmodel=kernel
> -funit-at-a-time -DCONFIG_X86_X32_ABI -DCONFIG_AS_CFI=1
> -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1
> -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1
> -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -pipe -Wno-sign-compare
> -fno-asynchronous-unwind-tables *** -O2 *** -Wframe-larger-than=1024
> -fno-stack-protector -Wno-unused-variable
> -Wno-format-invalid-specifier -Wno-gnu -Wno-asm-operand-widths
> -Wno-initializer-overrides -fno-builtin -Wno-tautological-compare
> -mno-global-merge -fno-omit-frame-pointer -fno-optimize-sibling-calls
> -pg -Wdeclaration-after-statement -Wno-pointer-sign
> -fno-strict-overflow -Werror=implicit-int -Werror=strict-prototypes
> -Werror=date-time -Wno-initializer-overrides -Wno-unused-value
> -Wno-format -Wno-unknown-warning-option -Wno-sign-compare
> -Wno-format-zero-length -Wno-uninitialized *** -Oz *** -DMODULE
> -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(video_detect)"
> -D"KBUILD_MODNAME=KBUILD_STR(video)" -c -o
> drivers/acpi/.tmp_video_detect.o drivers/acpi/video_detect.c
>
> How can I switch a optimization-cflags for certain code-parts in the
> Linux-kernel (with or without the kbuild-system)?
> ( So the default optimization-cflags is '-O2' whereas parts wants '-Os'. )
>
> What to do when using CONFIG_CC_OPTIMIZE_FOR_SIZE=y which sets '-Os' explicitly?
>
> Below tools/ directory we have also an OPTIMIZATION variable used.
>
> Something like a "global" solution is desired from my side.
>
> I have attached a patchset on top of my llvmlinux-amd64-fixes-4.4,
> hope this helps a bit to see what I mean.
> It is not doing what I desire - still WIP.
>
> Thoughts?
>
> Thanks in advance.
>

We have also hardcoded '-O2' in arch/x86...

$ grep '\-O2' -nr arch/x86/
arch/x86/boot/compressed/Makefile:24:KBUILD_CFLAGS := -m$(BITS)
-D__KERNEL__ $(LINUX_INCLUDE) -O2
arch/x86/entry/vdso/Makefile:67:CFL := $(PROFILING) -mcmodel=small
-fPIC -O2 -fasynchronous-unwind-tables -m64 \
arch/x86/um/vdso/Makefile:40:CFL := $(PROFILING) -mcmodel=small -fPIC
-O2 -fasynchronous-unwind-tables -m64 \

Is that explicitly required?

- Sedat -

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[One Thousand Gnomes]

> As said... I checked only for x86 and acpi only.
> 
> For example '-Os' is hardcoded in...
> 
> arch/x86/Makefile
> arch/x86/purgatory/Makefile
> 
> drivers/acpi/Makefile
> drivers/acpi/acpica/Makefile
> 
> For acpi part we have currently both used '-O2' and '-Os' ('-Oz' for
> llvmlinux) in approx 200 make-lines.

Certain parts of the kernel are built in particular ways for specific
reasons where the tradeoffs vary, or where people happen to know that -Os
is the best choice with gcc. Of course those may not be the same trade
offs for llvm.

> 
> $ grep '\-O2' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi | wc -l
> 226
> $ grep '\-Oz' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi |
> grep '\-O2' | wc -l
> 200
> 
> So, which optimization-cflags is now used if I have both in one
> make-line (and how can I check this)?

Consult the documentation for your compiler. GCC has an 810 page manual
that answers your question quite specifically

  "If you use multiple -O options with or without level numbers, the last
   such option is the one that is effective"


Don't assume they are contradictory options either. If you have other
optimnisations directly set then if those are after it they will take
effect

eg -Os -fprefetch-loop-arrays

is quite valid.

The GCC manual lists each optimisation it supports and documents exactly
which ones are enabled for each option. From that you should be able to
match them up with llvm.

> How can I switch a optimization-cflags for certain code-parts in the
> Linux-kernel (with or without the kbuild-system)?
> ( So the default optimization-cflags is '-O2' whereas parts wants '-Os'. )

Not sure I follow - that's exactly what the current Makefiles are doing.

> What to do when using CONFIG_CC_OPTIMIZE_FOR_SIZE=y which sets '-Os' explicitly?

That's something you'd need to work out as you regression test and profile
the codebase. A first guess would be to echo what gcc does but deal with
the unfortunate option difference between llvm and gcc.

It may also depend what "optimising for size" means to llvm. Some
compilers take it as a hint to favour smaller but still fast code, others
take it as an instruction to generate very tight but way slower code.
That will change which bits need which options.

Alan

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

On Mon, Jan 4, 2016 at 12:33 PM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
>> As said... I checked only for x86 and acpi only.
>>
>> For example '-Os' is hardcoded in...
>>
>> arch/x86/Makefile
>> arch/x86/purgatory/Makefile
>>
>> drivers/acpi/Makefile
>> drivers/acpi/acpica/Makefile
>>
>> For acpi part we have currently both used '-O2' and '-Os' ('-Oz' for
>> llvmlinux) in approx 200 make-lines.
>
> Certain parts of the kernel are built in particular ways for specific
> reasons where the tradeoffs vary, or where people happen to know that -Os
> is the best choice with gcc. Of course those may not be the same trade
> offs for llvm.
>
>>
>> $ grep '\-O2' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi | wc -l
>> 226
>> $ grep '\-Oz' build-log_4.4.0-rc8-2-llvmlinux-amd64.txt | grep acpi |
>> grep '\-O2' | wc -l
>> 200
>>
>> So, which optimization-cflags is now used if I have both in one
>> make-line (and how can I check this)?
>
> Consult the documentation for your compiler. GCC has an 810 page manual
> that answers your question quite specifically
>
>   "If you use multiple -O options with or without level numbers, the last
>    such option is the one that is effective"
>
>
> Don't assume they are contradictory options either. If you have other
> optimnisations directly set then if those are after it they will take
> effect
>
> eg -Os -fprefetch-loop-arrays
>
> is quite valid.
>
> The GCC manual lists each optimisation it supports and documents exactly
> which ones are enabled for each option. From that you should be able to
> match them up with llvm.
>
>> How can I switch a optimization-cflags for certain code-parts in the
>> Linux-kernel (with or without the kbuild-system)?
>> ( So the default optimization-cflags is '-O2' whereas parts wants '-Os'. )
>
> Not sure I follow - that's exactly what the current Makefiles are doing.
>
>> What to do when using CONFIG_CC_OPTIMIZE_FOR_SIZE=y which sets '-Os' explicitly?
>
> That's something you'd need to work out as you regression test and profile
> the codebase. A first guess would be to echo what gcc does but deal with
> the unfortunate option difference between llvm and gcc.
>
> It may also depend what "optimising for size" means to llvm. Some
> compilers take it as a hint to favour smaller but still fast code, others
> take it as an instruction to generate very tight but way slower code.
> That will change which bits need which options.
>

Thanks for your reply.

But I think you did not get my problem - to have two different
optimization-levels for a compiler in *one* make-line makes no sense
to me.

So, the kbuild-system adds optimization compiler-flags automatically -
see the upper/root Makefile.
Sort of "inheritance".

My question is how to set *one* optimization-level for whatever
compiler I use to build my Linux-kernel source.

-O1 || -O2 || -O3 || -O4 || -Os ('1..4' and 's' are so-called "optlevels")

It's still not clear if my problem is a compiler bug or not (see [1]
for the details).

Now a bit clearer?

- Sedat -

[1] http://marc.info/?t=144179442100006&r=1&w=1

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Michal Marek]

Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
> But I think you did not get my problem - to have two different
> optimization-levels for a compiler in *one* make-line makes no sense
> to me.

That we sometimes have -O2 ... -Os on the command line is not a problem,
since any same unix tool parses its options so that the last one of
mutually exclusive options wins. As to -Os vs. -Oz, to my knowledge
clang accepts both and -Oz means to reduce size by any means. If -Oz is
more appropriate for the CONFIG_CC_OPTIMIZE_FOR_SIZE case and/or for the
individual object files, feel free to change it, but please do not
introduce another variable holding compiler options.

Michal

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@suse.cz> wrote:
> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>> But I think you did not get my problem - to have two different
>> optimization-levels for a compiler in *one* make-line makes no sense
>> to me.
>
> That we sometimes have -O2 ... -Os on the command line is not a problem,
> since any same unix tool parses its options so that the last one of
> mutually exclusive options wins.

That is new to me and I haven't tested this by dropping arguments in
my make-line(s).

>From where do have this information - sort of "business-life-experience" :-)?
Is that documented somewhere in the Linux-sources?

What means "last one" - last one seen from the begin-of-(make)-line?

Do you agree that it is confusing to have two optlevel arguments in
one make-line?

Linus suggested me to use a wrapper-script in case of using two
different compiler and passing arguments...

[  /usr/bin/mycompiler ]
#!/bin/bash

gcc-4.9 "$@"
- EOF -

According to your statement passing an optlevel here in this script
will never-ever be recognized - as it is at the begin-of-(make)-line.

So how should someone change the Linux-sources to test a different
optlevel than -O2?

I have also seen that below arch/x86 there exists hardcoded -O2 and
-Os which are placed after -O2 (default value from the
toplevel-Makefile).

Thoughts?

> As to -Os vs. -Oz, to my knowledge
> clang accepts both and -Oz means to reduce size by any means. If -Oz is
> more appropriate for the CONFIG_CC_OPTIMIZE_FOR_SIZE case and/or for the
> individual object files, feel free to change it, but please do not
> introduce another variable holding compiler options.
>

JUST FYI...
I was able to compile a llvmlinux-patched Linux v4.4.-rc8 with -Os and
CLANG v3.7.1.
Dunno the difference between -Os and -Oz.
The bug-line still exists with both.

Still I want to know if the problem exists with a different optlevel
like -O0 or -O1 or -O3.
Cannot say if all clang-specific compiler-flags will be available in
these optlevels.
( Testing with hardcoded -O0 ended in a build-breakage. )
That would be helpful to check if it is a compiler-optimization bug.

Can you help me in having a switchable value for the "default"
optlevel (which is currently -O2) in the Kconfig system?

We have CC_OPTIMIZE_FOR_SIZE in init/Kconfig.

What about a CC_OPTIMIZE_DEFAULT as a string in init/Kconfig?

[ init/Kconfig ]

config CC_OPTIMIZE_DEFAULT
        string
        default="-O2"

config CC_OPTIMIZE_FOR_SIZE
        bool "Optimize for size"
        help
          Enabling this option will pass "-Os" instead of "-O2" to
          your compiler resulting in a smaller kernel.

          If unsure, say N.

[ Makefile (top-level ]

OPTIMIZE_CFLAGS := $(subst $(quote),,$(CC_OPTIMIZE_DEFAULT))
...
KCONFIG_CFLAGS += $(OPTIMIZE_CFLAGS)
...

Unfortunately, that is not working as expected.

Something like the above would help not to hack in the Linux-sources
and pass elegantly a default-optlevel via Kconfig-system.

If there is an easier way of passing and using a different optlevel,
then please let me know.

Still digging in the dark on how to change to have one single optlevel.

Is it in general possible to "override" the default -O2
(toplevel-Makefile) for a specific part/subsystem?
Other possibilities than via the Kconfig-system?

Thanks in advance.

- Sedat -

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@suse.cz> wrote:
> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>> But I think you did not get my problem - to have two different
>> optimization-levels for a compiler in *one* make-line makes no sense
>> to me.
>
> That we sometimes have -O2 ... -Os on the command line is not a problem,
> since any same unix tool parses its options so that the last one of
> mutually exclusive options wins.

That is new to me and I haven't tested this by dropping arguments in
my make-line(s).

From where do have this information - sort of "business-life-experience" :-)?
Is that documented somewhere in the Linux-sources?

What means "last one" - last one seen from the begin-of-(make)-line?

Do you agree that it is confusing to have two optlevel arguments in
one make-line?

Linus suggested me to use a wrapper-script in case of using two
different compiler and passing arguments...

[  /usr/bin/mycompiler ]
#!/bin/bash

gcc-4.9 "$@"
- EOF -

According to your statement passing an optlevel here in this script
will never-ever be recognized - as it is at the begin-of-(make)-line.

So how should someone change the Linux-sources to test a different
optlevel than -O2?

I have also seen that below arch/x86 there exists hardcoded -O2 and
-Os which are placed after -O2 (default value from the
toplevel-Makefile).

Thoughts?

> As to -Os vs. -Oz, to my knowledge
> clang accepts both and -Oz means to reduce size by any means. If -Oz is
> more appropriate for the CONFIG_CC_OPTIMIZE_FOR_SIZE case and/or for the
> individual object files, feel free to change it, but please do not
> introduce another variable holding compiler options.
>

JUST FYI...
I was able to compile a llvmlinux-patched Linux v4.4.-rc8 with -Os and
CLANG v3.7.1.
Dunno the difference between -Os and -Oz.
The bug-line still exists with both.

Still I want to know if the problem exists with a different optlevel
like -O0 or -O1 or -O3.
Cannot say if all clang-specific compiler-flags will be available in
these optlevels.
( Testing with hardcoded -O0 ended in a build-breakage. )
That would be helpful to check if it is a compiler-optimization bug.

Can you help me in having a switchable value for the "default"
optlevel (which is currently -O2) in the Kconfig system?

We have CC_OPTIMIZE_FOR_SIZE in init/Kconfig.

What about a CC_OPTIMIZE_DEFAULT as a string in init/Kconfig?

[ init/Kconfig ]

config CC_OPTIMIZE_DEFAULT
        string
        default="-O2"

config CC_OPTIMIZE_FOR_SIZE
        bool "Optimize for size"
        help
          Enabling this option will pass "-Os" instead of "-O2" to
          your compiler resulting in a smaller kernel.

          If unsure, say N.

[ Makefile (top-level ]

OPTIMIZE_CFLAGS := $(subst $(quote),,$(CC_OPTIMIZE_DEFAULT))
...
KCONFIG_CFLAGS += $(OPTIMIZE_CFLAGS)
...

Unfortunately, that is not working as expected.

Something like the above would help not to hack in the Linux-sources
and pass elegantly a default-optlevel via Kconfig-system.

If there is an easier way of passing and using a different optlevel,
then please let me know.

Still digging in the dark on how to change to have one single optlevel.

Is it in general possible to "override" the default -O2
(toplevel-Makefile) for a specific part/subsystem?
Other possibilities than via the Kconfig-system?

Thanks in advance.

- Sedat -

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Michal Marek]

On 2016-01-08 11:03, Sedat Dilek wrote:
> On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@suse.cz> wrote:
>> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>>> But I think you did not get my problem - to have two different
>>> optimization-levels for a compiler in *one* make-line makes no sense
>>> to me.
>>
>> That we sometimes have -O2 ... -Os on the command line is not a problem,
>> since any same unix tool parses its options so that the last one of
>> mutually exclusive options wins.
> 
> That is new to me and I haven't tested this by dropping arguments in
> my make-line(s).
> 
> From where do have this information - sort of "business-life-experience" :-)?
> Is that documented somewhere in the Linux-sources?

You override a previously set option by appending one with different value:

$ yes | head -n 10 -n 999 -n 2
y
y
$

This pattern is used all over in Makefiles.


> Do you agree that it is confusing to have two optlevel arguments in
> one make-line?

It probably is, but fixing this problem would make the Makefiles unreadable.


> Linus suggested me to use a wrapper-script in case of using two
> different compiler and passing arguments...
> 
> [  /usr/bin/mycompiler ]
> #!/bin/bash
> 
> gcc-4.9 "$@"
> - EOF -
> 
> According to your statement passing an optlevel here in this script
> will never-ever be recognized - as it is at the begin-of-(make)-line.

Pass it as the last argument.


> So how should someone change the Linux-sources to test a different
> optlevel than -O2?

make KCFLAGS=-O3

However, per-directory and per-file cflags set in Makefiles will take
precedence. If you want to override these as well, use the wrapper.

Michal

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

On Fri, Jan 8, 2016 at 12:31 PM, Michal Marek <mmarek@suse.cz> wrote:
> On 2016-01-08 11:03, Sedat Dilek wrote:
>> On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@suse.cz> wrote:
>>> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>>>> But I think you did not get my problem - to have two different
>>>> optimization-levels for a compiler in *one* make-line makes no sense
>>>> to me.
>>>
>>> That we sometimes have -O2 ... -Os on the command line is not a problem,
>>> since any same unix tool parses its options so that the last one of
>>> mutually exclusive options wins.
>>
>> That is new to me and I haven't tested this by dropping arguments in
>> my make-line(s).
>>
>> From where do have this information - sort of "business-life-experience" :-)?
>> Is that documented somewhere in the Linux-sources?
>
> You override a previously set option by appending one with different value:
>
> $ yes | head -n 10 -n 999 -n 2
> y
> y
> $
>
> This pattern is used all over in Makefiles.
>
>
>> Do you agree that it is confusing to have two optlevel arguments in
>> one make-line?
>
> It probably is, but fixing this problem would make the Makefiles unreadable.
>
>
>> Linus suggested me to use a wrapper-script in case of using two
>> different compiler and passing arguments...
>>
>> [  /usr/bin/mycompiler ]
>> #!/bin/bash
>>
>> gcc-4.9 "$@"
>> - EOF -
>>
>> According to your statement passing an optlevel here in this script
>> will never-ever be recognized - as it is at the begin-of-(make)-line.
>
> Pass it as the last argument.
>

How do I do that?

- Sedat -

>
>> So how should someone change the Linux-sources to test a different
>> optlevel than -O2?
>
> make KCFLAGS=-O3
>
> However, per-directory and per-file cflags set in Makefiles will take
> precedence. If you want to override these as well, use the wrapper.
>
> Michal

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Michal Marek]

On 2016-01-08 12:49, Sedat Dilek wrote:
> On Fri, Jan 8, 2016 at 12:31 PM, Michal Marek <mmarek@suse.cz> wrote:
>> On 2016-01-08 11:03, Sedat Dilek wrote:
>>> On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@suse.cz> wrote:
>>>> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>>> gcc-4.9 "$@"
>>> - EOF -
>>>
>>> According to your statement passing an optlevel here in this script
>>> will never-ever be recognized - as it is at the begin-of-(make)-line.
>>
>> Pass it as the last argument.
>>
> 
> How do I do that?

gcc-4.9 "$@" -O3

Michal

Re: Thoughts about introducing OPTIMIZATION_CFLAG

[Sedat Dilek]

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

On Fri, Jan 8, 2016 at 1:30 PM, Michal Marek <mmarek@suse.cz> wrote:
> On 2016-01-08 12:49, Sedat Dilek wrote:
>> On Fri, Jan 8, 2016 at 12:31 PM, Michal Marek <mmarek@suse.cz> wrote:
>>> On 2016-01-08 11:03, Sedat Dilek wrote:
>>>> On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@suse.cz> wrote:
>>>>> Dne 4.1.2016 v 12:47 Sedat Dilek napsal(a):
>>>> gcc-4.9 "$@"
>>>> - EOF -
>>>>
>>>> According to your statement passing an optlevel here in this script
>>>> will never-ever be recognized - as it is at the begin-of-(make)-line.
>>>
>>> Pass it as the last argument.
>>>
>>
>> How do I do that?
>
> gcc-4.9 "$@" -O3
>

Hmm, with that modification and my attached build-script I don't see
any -O3 passed to my generated make-lines.

[ /usr/bin/mycompiler ]
#!/bin/bash

clang "$@" -O3
- EOF -

What's wrong?

- Sedat -

[-- Attachment #2: build_llvmlinux.sh --]
[-- Type: application/x-sh, Size: 5148 bytes --]