[ROM][SIRIUS][KK][4.4.4][LINARO/SABERMOD] CyanogenMod 11 [NIGHTLY BUILDS][20150201]

• Compiled using sabermod arm-eabi 4.9.2 (kernel code) & sabermod arm-linux-androideabi 4.8.4 (rom code) toolchain compilers
• May contain some custom cherry-picks. Always check OP.
• Cross-compiled using those custom toolchains results in a more smoother, faster, and battery friendly ROM

In software, a toolchain is the set of programming tools that are used to create a product (typically another computer program or system of programs). The tools may be used in a chain, so that the output of each tool becomes the input for the next, but the term is used widely to refer to any set of linked development tools.
A simple software development toolchain consists of a compiler and linker to transform the source code into an executable program, libraries to provide interfaces to the operating system, and a debugger. A complex product such as a video game needs tools for preparing sound effects, music, textures, 3-dimensional models, and animations, and further tools for combining these resources into the finished product.

Click to expand...

Click to collapse

SaberMod is a AOSP based ROM with some extra features added in and mostly from CyanogenMod. SaberMod started out pure AOSP when android 4.2.1 launched. Originally it was pure AOSP with a few extra features I ported over from CyanogeMod and linaro optimizations. Then I rebased everything off of rasbeanjelly because I liked many features found in rasbean. Since then I've modified a lot of the code so not much of it is rasbeanjelly based anymore. But you will still find some commonly used features found in rasbeanjelly. SaberMod is not a rasbeanjelly or CM clone, or KANG. Custom kernels are included for certain devices when available. These are personal builds we make for ourselves and originally became very popular in the nexus 7 forums. Features are very rarely added, and are built to SaberMod's team members liking. Currently there are two members of SaberMod working on this project. Myself and @jarjar124 . Please understand our time is limited and we are only two people who have lives, and do not have 25-50 members like CyanogenMod to add things. And our goal is not to add a bunch of features that bloat the system of the ROM.

Click to expand...

Click to collapse

Linaro is the place where engineers from the world's leading technology companies define the future of Linux on ARM. The company is a not-for-profit engineering organization with over 120 engineers working on consolidating and optimizing open source software for the ARM architecture, including the GCC toolchain, the Linux kernel, ARM power management, graphics and multimedia interfaces.

Click to expand...

Click to collapse

Graphite has been around for a while in GCC. During this time a lot of people tested Graphite and Sebastian fixed many bugs. As of today the Graphite infrastructure is pretty stable and hosts already specific optimizations such as loop-interchange, blocking and loop-flattening.
However, during the development of Graphite we also found areas where we are still way behind our possibilities. First of all we realized that the use of a rational polyhedral library, even though it provides some functionality for integer polyhedra, is blocking us. Rational rational polyhedra worked OK for some time, but we have now come to a point where the absence of real integer polyhedra is causing problems. We have bugs that cannot be solved, just because rational polyhedra do not represent correctly the set of integer points in the loop iterations. Another deficit in Graphite is the absence of a generic optimizer. Even though classical loop transformations work well for certain problems, one of the major selling points of polyhedral techniques is the possibility to go beyond classical loop transformations and to forget about the corresponding pass ordering issues. Instead it is possible to define a generic cost function for which to optimize. We currently do not take advantage of this possibility and therefore miss possible performance gains. And as a last point, Graphite still does not apply to as much code as it could. We cannot transform a lot of code, not only because of the missing support for casts (for which we need integer polyhedra), but also because of an ad hoc SCoP detection and because some passes in the GCC pass order complicate Graphite's job. Moving these road blocks out of the way should increase the amount of code we can optimize significantly.

Click to expand...

Click to collapse