Okay, I got everything work so far building a room with aarch64-4.9 for both rom and kernel. But when I try to switch to 5.3 for kernel, I run in some issues. If I enable ARCHIDROID_GCC_CFLAGS_32 I get the error that this are unsupported options while compiling the rom. If I disable them, the kernel build fails with a parenthesis error. Am I thinking right that moving the flags from ARCHIDROID_GCC_CFLAGS_32 to ARCHIDROID_GCC_CFLAGS_64 might do the trick?
[COMMIT] [AOSP] JustArchi's ArchiDroid Optimizations V4.1 - Unleash the power!
- Thread starter JustArchi
- Start date
It's the change in the OP from ArchiDroid under fixes section labelled bluetooth. I honestly can't remember where I actually found said file, but I changed it and recompiled and everything worked correctly. I have to re do all my merges by hand because something got corrupted in my .git and .repo folders so I had to do a repo forall -vc "git reset --hard" and then wipe out some corrupted entries to fix things. It removed all the changes that I merged into those files by hand....
---------- Post added at 10:04 PM ---------- Previous post was at 10:03 PM ----------
Looks to me like something might not be merged in the right spot. I would check the changes in the core directory and make sure where you merged everything was correct. When I did it with Beanstalk almost none of the line numbers were right, and I had to correct a couple of the variables.
Thanks, I will check but I am sure I added all of it in the correct places and all the line numbers matched
What toolchain are you using? because you need a custom one for the optimizations, like UBERTC
I want to use UBERTC tool chain for building, so I added these lines to roomservice.xml:
But for some reason, I'm unable to start the building process:
I already deleted CCACHE. Everything works fine by using the normal toolchains. What's wrong?
Code:
<remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" />
<project name="UBERTC/arm-eabi-5.3" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="bitbucket" revision="master" />
<remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9" />
<project name="UBERTC/arm-linux-androideabi-5.3" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="bitbucket" revision="master" />But for some reason, I'm unable to start the building process:
Code:
sunsettrack4@jln-ubuntu:~/rr$ make clean
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=6.0.1
RR_VERSION=ResurrectionRemix-M-v5.6.4-20160309-slte
DEVICE=slte
TARGET_BUILD_VARIANT=user
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
TARGET_CPU_VARIANT=cortex-a15
TARGET_2ND_ARCH=
TARGET_2ND_ARCH_VARIANT=
TARGET_2ND_CPU_VARIANT=
TARGET_GCC_VERSION=4.9
TARGET_NDK_GCC_VERSION=4.9
HOST_ARCH=x86_64
HOST_OS=linux
HOST_OS_EXTRA=Linux-4.2.0-30-generic-x86_64-with-Ubuntu-15.10-wily
HOST_BUILD_TYPE=release
BUILD_ID=MMB29V
OUT_DIR=/home/sunsettrack4/rr/out
============================================
Checking build tools versions...
PRODUCT_COPY_FILES device/samsung/slte/configs/gps/gps.conf:system/etc/gps.conf ignored.
PRODUCT_COPY_FILES frameworks/av/media/libeffects/data/audio_effects.conf:system/etc/audio_effects.conf ignored.
PRODUCT_COPY_FILES device/generic/goldfish/data/etc/apns-conf.xml:system/etc/apns-conf.xml ignored.
PRODUCT_COPY_FILES device/generic/goldfish/camera/media_profiles.xml:system/etc/media_profiles.xml ignored.
PRODUCT_COPY_FILES device/generic/goldfish/camera/media_codecs.xml:system/etc/media_codecs.xml ignored.
PRODUCT_COPY_FILES hardware/libhardware_legacy/audio/audio_policy.conf:system/etc/audio_policy.conf ignored.
No private recovery resources for TARGET_DEVICE slte
Entire build directory removed.
#### make completed successfully (2 seconds) ####
sunsettrack4@jln-ubuntu:~/rr$used the toolchain archi provided, added the lines in roomservice.xml and repo synced, force synced his toolchain's
Maybe this folder doesn't exist in my project. I'll take a look at it, thanks! But why does the terminal show the wrong tool chain version (4.9 instead of UBERTC 5.3)?
Coz you've synced it in 4.9 dir
Don't remove the default ones, sync there in 5.3 folder
Then export TARGET_GCC_VERSION_EXP := 5.3
Sent from my Nexus 5X using Tapatalk
Do I have to add any extra fixes to compile kernel with 5.3 tool chain? Because I get error 1, I'll post a log as soon as I am back at home.
Gesendet von meinem SM-G920F mit Tapatalk
Gesendet von meinem SM-G920F mit Tapatalk
if you jumped right to 5.X toolchain from an older one, you'll need to fix many errors, you can find specific examples in my Github kernel repositories.
Is there the possibility to use arm-eabi-5.3 and arm-linux-androideabi-4.9 at the same time? When I use the TARGET_GCC_VERSION=5.3 command, the terminal wants to open the arm-linux-androideabi-5.3 files which shouldn't be used in my building process ...
Gesendet von meinem SM-G920F mit Tapatalk
That flag is for androideabi, for compiling ROM
Set 4.9
To use the 5.3 for kernel, KERNEL_TOOLCHAIN := /path/to/arm-eabi-5.3/bin
Sent from my Nexus 5X using Tapatalk
I don't know why I always get this error without any mentioned reasons, even by using UBERTC 4.9:
Code:
Makefile:130: recipe for target 'sub-make' failed
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory '/home/sunsettrack4/rr/kernel/samsung/slte'
build/core/tasks/kernel.mk:286: recipe for target 'TARGET_KERNEL_BINARIES' failed
make: *** [TARGET_KERNEL_BINARIES] Error 2Yep, I found it:
Code:
/home/sunsettrack4/rr/kernel/samsung/slte/include/linux/compiler-gcc.h:103:30: fatal error: linux/compiler-gcc5.h: No such file or directory
compilation terminated.
/home/sunsettrack4/rr/kernel/samsung/slte/scripts/mod/Makefile:34: recipe for target 'scripts/mod/devicetable-offsets.s' failed
make[4]: *** [scripts/mod/devicetable-offsets.s] Error 1
/home/sunsettrack4/rr/kernel/samsung/slte/scripts/Makefile.build:455: recipe for target 'scripts/mod' failed
make[3]: *** [scripts/mod] Error 2
make[3]: *** Auf noch nicht beendete Prozesse wird gewartet …But what about the other errors?
You can expect a lot more[emoji14]You can have a look at https://github.com/akhilnarang/ThugLife_falcon/commits/master about page 4/5, should have gcc5 fixes
Sent from my Nexus 5X using Tapatalk
Still getting bluetooth fc after applying "-Os" to LOCAL_CFLAGS" in system/bt,here is the logcat for it
View attachment logcat_13_3.zip
after applying the flag,just did a clean build "make clean/clobber AND empty ccache (rm -rf ~/.ccache)" as mention in op,getting the same result.
View attachment logcat_13_3.zip
after applying the flag,just did a clean build "make clean/clobber AND empty ccache (rm -rf ~/.ccache)" as mention in op,getting the same result.
Did you really put it here?
https://github.com/CyanogenMod/android_system_bt/blob/cm-13.0/main/Android.mk#L137
Similar threads
- Poll
Top Liked Posts
-
There are no posts matching your filters.
-
695Hello dear developers.
I'd like to share with you effect of nearly 300 hours spent on trying to optimize Android and push it to the limits.
In general. You should be already experienced in setting up your buildbox, using git, building AOSP/CyanogenMod/OmniROM from source and cherry-picking things from review/gerrit. Solving git conflicts would also be nice. If you don't know how to build your own ROM from source, this is not a something you can apply to your ROM. Also, as you probably noticed, this is not a something you can apply to already prebuilt ROM (stocks), as these optimizations are applied during compilation, so only AOSP roms, self-compiled from source may use this masterpiece.
So, what is it about? As we know, Android contains a bunch of low-level C/C++ code, which is compiled and acts as a backend for our java's frontend and android apps. Unfortunately, Google didn't put their best at focusing on optimization, so as a result we're using the same old flags set back in 2006 for Android Donut or anything which existed back then. As you guess, in 2006 we didn't have as powerful devices as now, we had to sacrifice performance for smaller code size, to fit to our little devices and run well on very low amount of memory. However, this is no longer a case, and by using newest compilers and properly setting flags, we can achieve something great.
You probably may heard of some developers claiming using of "O3 Flags" in their ROMs. Well, while this may be true, they've applied only to low-level ARM code, mostly used during kernel compilation. Additionally it overwrites O2 flag, which is already fast, so as you may guess, this is more likely a placebo effect and disappears right after you change the kernel. Take a look at the most cherry-picked "O3 Flags commit". You see big "-Os" in "TARGET_thumb_CFLAGS"? This is what I'm talking about.
However, the commit I'm about to present you is not a placebo effect, as it applies flags to everything what is compiled, and mostly important - target THUMB, about 90% of an Android.
Now I'll tell you some facts. We have three interesting optimization levels. Os, O2, O3. O2 enables all optimizations that do not involve a space-speed tradeoff. Os is similar to O2, but it disables all flags that increase code size. It also performs further optimizations to reduce code size to the minimum. O3 enables all O2 optimizations and some extra optimizations that like to increase code size and may, or may not, increase performance. If you want to ask if there's something more like O4, there is - Ofast, however it breaks IEEE standard and doesn't work with Android, as i.e. sqlite3 is not compatible with Ofast's -ffast-math flag. So no go for us.
Now here comes the fun part. Android by default is compiled with O2 flag for target ARM (about 10% of Android, mostly low-level parts) and Os flag for target THUMB (about 90% of Android, nearly everything apart from low-level parfts). Some guys think that Os is better than O2 or O3 because smaller code size is faster due to better fitting in cpu cache. Unfortunately, I proven that it is a myth. Os was good back in 2006, as only with this flag Google was able to compile Dalvik and it's virtual machine while keeping good amount of free memory and space on eMMC cards. As or now, we have plenty of space, plenty of ram, plenty of CPU power and still good old Os flag for 90% of Android.
I've made countless tests to find out what is the most efficient in terms of GCC optimization, two selected tests I am about to present you right now.
As you may noticed, I compiled whetstone.c benchmark using three different optimization flags - Os, O2 and O3. I set CPU to performance, maximum frequency, and I repeated each test additional two times, just to make sure that Android doesn't lie to me. Source code of this test is available here and you may download it, compile for our beloved Android and try yourself. As you can see O3 > O2 >> Os, Os performs about 2.5x times worse than O2, and about 3.0x times worse than O3.
But, of course. Android is not a freaking benchmark, it's operating system. We can't tell if things are getting better or worse according to a simple benchmark. I kept that in mind and provided community with JustArchi's Mysterious Builds for test. I gave both mysterious builds and didn't tell my users what is the mysterious change. Both builds have been compiled with the same toolchain, same version, same commits. The one and only mysterious change was the fact that every component compiled as target thumb (major portion of an android) has been optimized for speed (O3) in build #1 (experimental), and optimized for size (Os) in build #2 (normal behaviour). Check poll yourself, 9 votes on build 1 in terms of performance, and 1 vote on build 2. I decided that this and benchmark is enough to tell that O2/O3 for target thumb is something that we want.
Now it doesn't matter that match if you wish to use O2 or O3, but here is some comparison:
1. Kernel compiled with O2 has 4902 KB, with O3 4944 KB, so O3 is 42 KB bigger.
2. ROM compiled with O3 is 3 MB larger than O2 after zip compression. Fast overview: 97 binaries in /system/bin and 2 binaries in /system/xbin + 283 libraries in /system/lib and other files, about 400 files in total. 3 MB / 400 = 7,5 KB per file size increase.
3. It's unlikely that code working properly with O2 level might break on O3 level, most issues are on the Os <-> O2 part.
4. If it doesn't cause any issues, and speeds up a binary by a little bit, why not use it?
5. The only real reason to not use O3 is potential higher memory usage due to oversized binaries.
In general, I doubt that this extra chunk of code may cause any significant memory usage or slower performance. I suggest to use O3 if it doesn't cause any issues to you compared to O2, but older devices may use O2 purely for saving on code size, similar way Google did it back in 2006 using Os flag.
[SIZE="+1"]Now let's get down to business[/SIZE].
Here is a list of important improvements:
Sound cool, doesn't it? Head over to my ArchiDroid project and see yourself how people react after switching to my ROM. Take a look at just one small example, or another one
. No bullsh*t guys, this is not a placebo.
However, please read my commit carefully before you decide to cherry-pick it. You must understand that Google's flags weren't touched since 7 years and nobody can assure you that they will work properly for your ROM and your device. You may experiment with them a bit to find out if they're not causing conflicts or other issues.
I can assure you that my ArchiDroid based on CM compiles fine with suggested steps written in the commit itself. Just don't forget to clean ccache (rm -rf /home/youruser/.ccache or rm -rf /root/.ccache) and make clean/clobber.
You can use, modify and share my commit anyway you want, just please keep proper credits in changelogs and in the repo itself. If you feel generous, you may also buy me a coke for massive amount of hours put into those experiments.
Now go ahead and show your users how things should be done.
Cherry-picking time!
Android "Lollipop" (5.1.1 & 5.0.2 tested)
JustArchi's ArchiDroid Optimizations V4.1 for CyanogenMod (latest)
A set of commits you may want to pick to fix O3-related issues:
external_bluetooth_bluedroid | hardware_qcom_display | libcore | frameworks_av #1 | frameworks_av #2
Older entries are provided for reference only. I suggest using only latest commit above.
Android "Lollipop" (5.1.1 & 5.0.2 tested)
JustArchi's ArchiDroid Optimizations V4 for CyanogenMod
Android "Kitkat" 4.4.4:
JustArchi's ArchiDroid Optimizations V3 for CyanogenMod
JustArchi's ArchiDroid Optimizations V3 for OmniROM
JustArchi's ArchiDroid Optimizations V2
JustArchi's ArchiDroid Optimizations V1
AFTER applying above commit and AFTER EVERY CHANGE regarding flags, ALWAYS make clean/clobber AND empty ccache (rm -rf ~/.ccache)
Q: How to properly change toolchains used in local manifest?
Open from your source rootdir .repo/local_manifests/roomservice.xml (or create one). Here is a sample manifest that replaces default 4.8 toolchain (both eabi and androideabi) with 4.8 SaberMod and 4.9 ArchiToolchain:
Code:<?xml version="1.0" encoding="UTF-8"?> <manifest> <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" /> <project name="ArchiDroid/Toolchain" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="architoolchain-5.2-arm-linux-gnueabihf" /> <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" /> <project name="ArchiDroid/Toolchain" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="uber-4.9-arm-linux-androideabi" /> </manifest>
This is only an example, you should use the toolchains that suit you best. My ArchiDroid/Toolchain github repo is a good start to test various different toolchains and decide which one you like the most, or which one causes the least problems for you. I do not suggest any other magic tricks to include custom toolchains, putting your selected one in proper path is enough, avoid magic android_build modifications.
[size=+1]Troubleshooting[/size]
Q: Compiler errror:
Code:(...)/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/../libexec/gcc/arm-linux-androideabi/4.8.x-sabermod/cc1: error while loading shared libraries: libcloog-isl.so.4: cannot open shared object file: No such file or directory
This error can be fixed by installing missing library. libcloog-isl.so.4 is provided by libcloog-isl4 package, so on debian-like OSes, you should be able to fix it with:
Code:apt-get install libcloog-isl4
Q: Compiler errror:
Code:(...)/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/../libexec/gcc/arm-linux-androideabi/4.8.x-sabermod/cc1: error while loading shared libraries: libisl.so.13: cannot open shared object file: No such file or directory
This error is very similar to above, but considers other shared library. libisl.so.13 is provided by libisl13 package. Now the problem is that this package is in testing/sid, so we'll need to install it from there.
Add to your /etc/apt/sources.list following entries:
Code:deb http://ftp.debian.org/debian testing main contrib non-free deb-src http://ftp.debian.org/debian testing main contrib non-free
Then apt-get update && apt-get install libisl13.
Issues below are for older commits and should be used for reference only
Kitkat THUMB O2+ errors?
These are the most common issues.
* Change -O3 flag from TARGET_thumb_CFLAGS back to -Os, make clean/clobber, empty ccache and try again. This fixes most of the issues.
* RIL problems for for the Exynos 4210 family? Add -fno-tree-vectorize to TARGET_thumb_CFLAGS.
* Broken exFAT -> https://github.com/JustArchi/android_external_fuse/commit/78ebbc4404de260862dca5f0454bffccee650e0d
Errors caused by toolchain?
1. Try Google's GCC 4.8 if you used Linaro 4.8 or SaberMod 4.8
2. Fallback to Google's GCC 4.7 if above didn't help (change TARGET_GCC_VERSION back to 4.7)
Errors caused by GCC 4.8+?
* ART Fix (bootloop) -> https://github.com/JustArchi/android_art/commit/71a0ca3057cc3865bd8e41dcb94443998d028407
* Not booting kernel -> https://github.com/JustArchi/androi...mmit/9262707f4ea471acf40baa43ffe4bfb3cff64de9 and https://github.com/JustArchi/androi...mmit/41a70abcdad746d9415f3ee40f90528feb0c9bdd
Errors caused by GCC 4.9+?
* Graphical glitches in PlayStore -> https://github.com/JustArchi/android_external_webp/commit/36c6201fbb108d6b757f860e2cd57f3982191662
Errors caused by Linaro?
* error: unknown CPU architecture -> https://github.com/JustArchi/androi...mmit/5e5e158a7c147725beae1eeb6785174baacecb03 (Keep in mind that this is a sample fix for smdk4412 kernel, you may need to use similar solution in your own case. Also, this error happens only with Linaro toolchain, doesn't happen with Google's GCC)
Other errors?
* error: undefined reference to 'memmove' -> https://github.com/XperiaSTE/androi...mmit/679a4e571ef77f47892a785e852d8219c1e6807a
[size=+1]Credits[/size]
@IAmTheOneTheyCallNeo - For inspiration and first steps
@metalspring - For some nice commits
@sparksco - For SaberMod, some nice commits and support for the optimization idea33Hello dear developers.
I'd like to share with you effect of nearly 200 hours spent on trying to optimize Android and push it to the limits.
In general. You should be already experienced in setting up your buildbox, using git, building AOSP/CyanogenMod/OmniROM from source and cherry-picking things from review/gerrit. If you don't know how to build your own ROM from source, this is not a something you can apply to your ROM. Also, as you probably noticed, this is not a something you can apply to every ROM, as these optimizations are applied during compilation, so only AOSP roms, self-compiled from source may use this masterpiece.
So, what is it about? As we know, Android contains a bunch of low-level C/C++ code, which is compiled and acts as a backend for our java's frontend and android apps. Unfortunately, Google didn't put their best at focusing on optimization, so as a result we're using the same old flags set back in 2006 for Android Donut or anything which existed back then. As you guess, in 2006 we didn't have as powerful devices as now, we had to sacrifice performance for smaller code size, to fit to our little devices and run well on very low amount of memory. However, this is no longer a case, and by using newest compilers such as GCC 4.8 and properly setting flags, we can achieve something, which I call "Android in 2014".
You probably may heard of some developers claiming using of "O3 Flags" in their ROMs. Well, while this may be true, they've applied only to low-level ARM code, mostly used during kernel compilation. Additionally it overwrites O2 flag, which is already fast, so as you may guess, this is more likely a placebo effect and disappears right after you change the kernel. Take a look at the most cherry-picked "O3 Flags commit". You see big "-Os" in "TARGET_thumb_CFLAGS"? This is what I'm talking about.
However, the commit I'm about to present you is not a placebo effect, as it applies flags to everything what is compiled, and mostly important - target THUMB, about 90% of an Android.
Now I'll tell you some facts. We have three interesting optimization levels. Os, O2, O3. O2 enables all optimizations that do not involve a space-speed tradeoff. Os is similar to O2, but it disables all flags that increase code size. It also performs further optimizations to reduce code size to the minimum. O3 enables all O2 optimizations and some extra optimizations that like to increase code size and may, or may not, increase performance. If you want to ask if there's something more like O4, there is - Ofast, however it breaks IEEE standard and doesn't work with Android, as i.e. sqlite3 is not compatible with Ofast's -ffast-math flag. So no go for us.
Now here comes the fun part. Android by default is compiled with O2 flag for target ARM (about 10% of Android, mostly kernel) and Os flag for target THUMB (about 90% of Android, nearly everything apart from kernel). Some guys think that Os is better than O2 or O3 because smaller code size is faster due to bettering fitting in cpu cache. Unfortunately, I proven that it is a myth. Os was good back in 2006, as only with this flag Google was able to compile Dalvik and it's virtual machine while keeping good amount of free memory and space on eMMC cards. As or now, we have plenty of space, plenty of ram, plenty of CPU power and still good old Os flag for 90% of Android.
Now you should ask - where is your proof?, here I have it for you:
As you may noticed, I compiled whetstone.c benchmark using three different optimization flags - Os, O2 and O3. I repeated each test additional two times, just to make sure that Android doesn't lie to me. Source code of this test is available here and you may download it, compile for our beloved Android and try yourself. As you can see O3 > O2 >> Os, Os performs about 2.5x times worse than O2, and about 3.0x times worse than O3.
But, of course. Android is not a freaking benchmark, it's operating system. We can't tell if things are getting better or worse according to a simple benchmark. I kept that in mind and provided community with JustArchi's Mysterious Builds for test. I gave both mysterious builds and didn't tell them what is the mysterious change. Both builds have been compiled with the same toolchain, same version, same commits. The one and only mysterious change was the fact that every component compiled as target thumb (major portion of an android) has been optimized for speed (O3) in build #1 (experimental), and optimized for size (Os) in build #2 (normal behaviour). Check poll yourself, 9 votes on build 1 in terms of performance, and 1 vote on build 2. I decided that this and benchmark is enough to tell that O2/O3 for target thumb is something that we want.
Now the battle is, O2 or O3? This is tough choice, here are some facts:
1. Kernel compiled with O2 has 4902 KB, with O3 4944 KB, so O3 is 42 KB bigger.
2. ROM compiled with O3 is 3 MB larger than O2 after zip compression. Fast overview: 97 binaries in /system/bin and 2 binaries in /system/xbin + 283 libraries in /system/lib and other files, about 400 files in total. 3 MB / 400 = 7,5 KB per file size increase.
3. No issues
In general, I doubt that this extra chunk of code may cause any significant memory usage or slower performance. I suggest to use O3 if it doesn't cause any issues to you compared to O2, but older devices may use O2 purely for saving on code size, similar way Google did it back in 2006 using Os flag.
[SIZE="+1"]Now let's get down to bussiness[/SIZE].
Here is a link to the commit -> https://github.com/JustArchi/android_build/commit/8e1b82c082a8de9160e6c0fc3ded37b591c3e517
And here is a list of important improvements:
Looks badass? It is badass. Head over to my ArchiDroid 2.X project and see yourself how people react after switching to my ROM. Take a look at just one small example, or another one. No bullsh*t guys, this is future.
However, please read my commit carefully before you decide to cherry-pick it. You must understand that Google's flags weren't touched since 7 years and nobody can assure you that they will work properly for your ROM and your device. You may experiment with them a bit to find out if they're not causing conflicts or other issues.
I can assure you that my OmniROM build compiles fine with some fixes mentioned in the commit itself. Just don't forget to clean ccache (rm -rf /home/youruser/.ccache or rm -rf /root/.ccache) and make clean/clobber.
You can use, modify and share my commit anyway you want, just please keep proper credits in changelogs and in the repo itself. If you feel generous, you may also buy me a coke for massive amount of hours put into those experiments.
Now go ahead and show your users how things should be done.
I do agree that the most cherry-picked commit you linked is terrible, and while this is some nice work you've done, it's misleading and not entirely true.
Android is NOT 90% thumb. I'd give it a maximum of 50%, and that's being extremely generous. On Linaro's website I recall reading about potential future experiments for them, and one of them was to see what else could be improved by using thumb. If Android is already 90% thumb, that'd be a useless task and you might as well compile everything as thumb, and looking at my build logs there's plenty more things compiled as ARM than there are thumb.
I agree that the people saying usage of -Os is good are way out of date and stuck in the past. With older ARM chips it was a good idea, but anything Cortex-A9 (if not Cortex-A8) and newer is plenty good enough for at least -O2.
The kernel's compiler flags are all defined in the kernel itself. None of the flags in the build section of Android end up in the kernel.
There are a number of "changes" you've made which actually didn't do anything:
1. -DNDEBUG was already defined in TARGET_RELEASE_CFLAGS, which if I remember correctly is just all appended or prepended (doesn't matter which it is in this case) to your usual TARGET_arm_CFLAGS and TARGET_thumb_CFLAGS, so debugging code was already disabled.
2. The -fgcse-after-reload and -funswitch-loops flags are already enabled by using -O3, so it is not necessary nor helpful to add it by hand.
3. The -frename-registers flag was already enabled in TARGET_RELEASE_CFLAGS, as was -fomit-frame-pointer, so again these additions have no effect or change.
4. The -frerun-cse-after-loop is already enabled by using -O3 and it's even enabled at as low as -Os, so this is unnecessary as well and even in the unmodified build flags would already be there.
There is a flag which you've stated is broken, but actually works just fine and can be extremely beneficial: -flto (Link-Time Optimization).
I've been using LTO for at least 5 months now.
You're also missing out on using C++11, this allows for some extra optimizations as well.
There is a change you've made which is EXTREMELY DANGEROUS and could result in crashes or maybe even worse:
You've used the "-Wno-error=strict-aliasing" flag. strict-aliasing is a fatal error by default for a reason!! You should definitely give this a read: http://cellperformance.beyond3d.com/articles/2006/06/understanding-strict-aliasing.html
Fixing those violations is extremely time-consuming, and resulted in me having to fork over 30 git repos to do so, but if I didn't do that I could end up being responsible for the loss of data on a thousand or more devices. I don't want something like that on my conscious.
Now, I've never been one to try and advertise my work or say my work is better than other people's, but I've been hearing about stuff like this for a long time now and I'm getting sick and tired of it.
My GitHub: https://github.com/MWisBest/
My ROM's thread: http://xdaforums.com/galaxy-nexus/verizon-develop/rom-fml-fork-life-01-09-2014-t2427087/
If you take a look at my thread you'll see I'm extremely humble. Heck, if somebody posts that they've moved on to/liked a different ROM better, I'm actually happy that they've found something they like! All I hope for is that people find a ROM they like. If it's mine, great! If it's not, that's just dandy too! I don't boast about the amount of users my ROM has, I don't brag about (let alone bring up) being the first person to get a KitKat ROM on the VZW Galaxy Nexus, etc. I'm not in this for fame and internet points. My expectation when I released my ROM was for it to just fall back page by page and have just a few users.
I don't know how long you've been working on this stuff, but I've been working on it for 9 months and I'm constantly refining and improving it. I don't claim to be an expert at it, but compared to the people that get attention for similar work I'd say what I've done is better. To put what I've just said into perspective: That is the only time I've ever said anything I've done is better than somebody else here.
I've been sitting here debating whether or not to press the "Submit Reply" button, in the end I decided that the risks of people using the work posted here outweigh any potential negative outcome from me submitting this post.18I'm working on CM12 for my beloved i9300, it's in alpha stage, but it works correctly in terms of Android, so I think that I'll start working on V4 for Lollipop soon. But it will take a few weeks more, I need to be sure that there are no upstream bugs before starting to... generate them.18Just because some of you are wondering.
Yes, I'm testing how M works with my optimizations, with UBERTC toolchains, and testing which newly introduced or previously disabled (for compatibility reasons) flags may work again. If you need simple copy-pasta that should work properly, you can find it here and don't forget to click thanks. In the meantime I'm working on V5 for M, which will come at some point, when I test that everything works for at least 2, preferably 3 of my devices, including ARM64 one - OnePlus 2, which is now my main device.
As I said many times, it's kind of long process, because every flag has to be carefully tested, and because it's being applied globally - also with caution. Full builds take time, tests as well. This commit is already "too device-based", and may require additional fixes for you, so the point now is to require as few as possible, while being compatible with as many as possible devices out of the box.
So yeah, it will come out, eventually.
New posts
-
-
I have a problem with rear camera settings on Junsun V1 Pro (I need help)
- Latest: www_marek@op.pl
-
