| Message ID | CA+icZUVEs_+XiWeqtJ+34HBSx5LJYyEgoo2DLFzVr6yc9oxx2Q@mail.gmail.com (mailing list archive) |
|---|---|
| State | Not Applicable, archived |
| Headers | show |
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 - -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 - -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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 -
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
[ 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 -