Hi, I've had a look at the 4.2 tree last night, and started rebasing our stuff. A couple of notable changes, some of which may require some extra work:
- Some Ethernet support was added. In the rebased version, I've dropped the frameworks/base part of the ECM bits (because something similar is already there). We may have to modify the ECM settings bits to work with the new Ethernet stuff or bring back ECM if it turns out to be more powerful - fake vsync is now supported out of the box, our patch for that is no longer needed. The property has a different name though - if anything uses sf.force_sw_vsync, it needs to be updated to use debug.sf.no_hw_vsync - Bluez was dropped in favor of a new Bluetooth stack. I doubt this affects any of our builds a lot. - the "prebuilts" tree now includes "platform/prebuilts/clang/linux-x86/3.2", looks like someone is considering to move away from gcc. It'll be interesting to benchmark this against Linaro gcc (if llvm 2.9 is any indication, its optimization will come nowhere near ours - but of course they haven't been sitting around idle)
I've pushed a linaro_android_4.2 tree, but it's not ready yet (in particular, only the galaxynexus manifest has been updated, trying to get one build up first).
ttyl bero
On 15 November 2012 02:23, Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
Hi, I've had a look at the 4.2 tree last night, and started rebasing our stuff. A couple of notable changes, some of which may require some extra work:
- Some Ethernet support was added. In the rebased version, I've dropped the
frameworks/base part of the ECM bits (because something similar is already there). We may have to modify the ECM settings bits to work with the new Ethernet stuff or bring back ECM if it turns out to be more powerful
- fake vsync is now supported out of the box, our patch for that is no
longer needed. The property has a different name though - if anything uses sf.force_sw_vsync, it needs to be updated to use debug.sf.no_hw_vsync
- Bluez was dropped in favor of a new Bluetooth stack. I doubt this affects
any of our builds a lot.
- the "prebuilts" tree now includes
"platform/prebuilts/clang/linux-x86/3.2", looks like someone is considering to move away from gcc. It'll be interesting to benchmark this against Linaro gcc (if llvm 2.9 is any indication, its optimization will come nowhere near ours - but of course they haven't been sitting around idle)
It could be used for Renderscript, a static checker, or many other things apart from the static C compiler. We'll see.
-- Michael
On 14 November 2012 21:31, Michael Hope michael.hope@linaro.org wrote:
On 15 November 2012 02:23, Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org wrote:
"platform/prebuilts/clang/linux-x86/3.2", looks like someone is
considering
to move away from gcc. It'll be interesting to benchmark this against
Linaro
gcc (if llvm 2.9 is any indication, its optimization will come nowhere
near
ours - but of course they haven't been sitting around idle)
It could be used for Renderscript, a static checker, or many other things apart from the static C compiler. We'll see.
There's some odd stuff going on there... They've added a new keyword to the Android.mk makefiles - you can now set
LOCAL_CLANG := true
in order to build a project with clang as opposed to whatever compiler is being provided.
Inside AOSP itself, LOCAL_CLANG is set for
frameworks/support/renderscript/v8/rs_support frameworks/rs external/compiler-rt external/compiler-rt/lib external/compiler-rt/lib/asan external/libpng
That's renderscript related bits, compiler-rt (that library looks a lot like a libgcc replacement to me), and libpng.
At least libpng strikes me as something that could just as easily be built with gcc (and it was up until 4.1) Looks like they force clang wherever they use -ftrapv -- maybe it's a workaround for a -ftrapv breakage in [their version of] gcc?
ttyl bero
linaro-android@lists.linaro.org
-
Bernhard Rosenkränzer -
Michael Hope