On Mon, Jan 4, 2016 at 11:37 PM, Michal Marek <mmarek@xxxxxxx> 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-kbuild" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
