== Progress ==
* AARCH64 - Gprof support.
Make GCC generate profile information (On-going).
Defined hook and macros in GCC to emit "mcount" instrumented calls.
Looked at ARM implementation and veener code in glibc which implements mcount.
Discussed with Matt, and decided to use generic "mcount"
implementation in glibc for aarch64.
The generic uses built_in_return_address. Looking at defining macros
and function which traverses
frames back and returns the desired frame address.
== Plan ==
* Continue gprof support work for Aarch64
Planned leaves:
1 May: Labor Day's holiday.
== Summary ==
- http://cards.linaro.org/browse/TCWG-14
- ran into space issues with chromebook and issues running spec2000
locally due to that. Finally reinstalled Ubuntu on 32GB card and set-up
everything.
- There is a potential issue with zero/sign extension based VRP.
- 254.gap goes into infinite loop. Investigating it.
- checked VRP for improvement of zero/sign extension (missing case
in CRC).
== Plan==
- http://cards.linaro.org/browse/TCWG-14
- Find the cause for 254.gap infinite loop and fix it.
- Find a solution to missing case in CRC
Summary:
* Enhance Linaro crosstool-ng.
Details:
1. Work with Bero to release 4.8 binary build.
2. Update Linaro crosstool-ng to use ISL/CLooG for 4.8 build (lp:1172595).
3. Rebase conditional compare experimental codes to lp:gcc-linaro/4.8.
Plan:
* Investigate the impact of conditional compare on optimizations.
Planned leaves:
* 29 April - 1 May: Labor Day's holiday.
Best Regards!
-Zhenqiang
== Issues ==
* None
== Progress ==
* Libunwind AArch64 support:
- Fixed signal frame issue.
- Sent patch upstream for review.
- Delivered patch to OE team for early testing.
* LRA on ARM and AArch64:
- Start to look at what is missing.
== Plan ==
* 3 days off next week
* Continue on LRA.
Hi,
I need following packages for ARMv8 (aarch64) target. Where can I find
these packages? Or do I have to download source code and compile those
using linaro-cross-compiler?
libqt4-dev libqt4-opengl-dev libphonon-dev libicu-dev libsqlite3-dev
libxext-dev libxrender-dev gperf libfontconfig1-dev libphonon-dev
libpng12-dev libjpeg62-dev
Thanks
Aparna
== Progress ==
* Benchmarks
- Running EEMBC on a Panda
- LLVM on par with GCC in code size and run time
* Release Planning
- Calxeda busted, delays, but got test-suite running on it
- Bootstrap and test-suite fail with atomic support, investigating
- Preparing a Beagleboard for conscience relief
- Coordinating with other parties on hardware/testing/roles
* EuroLLVM 2013
- Meetings, badges, preparations, final run
* Support
- Helping folks with test-suite, buildbots, reviewing patches, etc
== Issues ==
Broke my glasses on a place impossible to fix, had to resort to epoxy while
I wait for an eye test
== Plan ==
* EuroLLVM Mon~Tue
* Continue setting up release hardware/process, order some more boards
* Help Sylvestre/Galina setting up Jenkins/Buildbots for release
* Try to run a more substantial benchmark
* Fix my glasses
== Progress ==
* Disable-peeling: had to re-spawn benchmark jobs (both reference and
updated patch)
* Libsanitizer: updated patch running under cbuild before updating my
proposal upstream.
* Neon intrinsics:
- some progress on removing unnecessary moves around vuzp.
- there are still some around veor
* Bi-endian compiler: read article, attended call
* Internal support
== Next ==
Holidays next week
== Future ==
* Disable peeling: analyze results
* Revert-coalesce: same
* Libsanitizer: sent updated patch upstream if validation OK
* Neon intrinsics: continue improving crc with vuzp
== Progress ==
* Submitted binutils patch for testsuite failure on precise.
* Updated glibc memcpy patch based on feedback.
* Updated binutils IFUNC patch based on feedback.
* Started working on AArch64 IFUNC.
* Submitted a couple of cleanup patches for AArch64 binutils.
== Issues ==
* 2 cards blocked on upstream review, 1 blocked on Android team.
== Plan ==
* Should get binutils IFUNC patch committed Monday.
* Need to ping other patches again.
* More work on AArch64 IFUNC.
--
Will Newton
Toolchain Working Group, Linaro
Progress:
* office move
* VIRT-49:
** confirmed I can run KVM on the Arndale, started using it as
test platform for the migration work
** I have most of the code for cp15 register migration written
** in debug phase; there is a case I hadn't considered that needs a
little thought
Plans:
* keep pushing on with VIRT-49
* book travel/hotel for Connect Dublin
* office move unpacking
-- PMM
Hi.
First.
#include <Im-doing-something-somewhat-odd.h>
I'm trying to use a current clang/llvm (current as in git checkout
from just the other day) to build an opencl kernel and then link that
with some code which has been compiled with gcc/g++.
When the clang .o is linked to the gcc/gcc+, I'm getting
/home/tgall/opencl/SNU/tmp2/cl_temp_1.tkl uses VFP register arguments,
/home/tgall/opencl/SNU/tmp2/cl_temp_1.o does not
the cl_temp_1.o was produced with clang.
the cl_temp_1.tkl via gcc/g++.
Let's dive into details.
This is following in the footsteps of an open source framework called
SNU which implements OpenCL. Within SNU they had a fairly old version
of clang+llvm which wouldn't even build on ARM so step one has been to
figure out what SNU was doing with clang and replicate this using
latest clang.
So given the following minimal test kernel placed into cl_temp_1.cl
/* Header to make Clang compatible with OpenCL */
#define __global __attribute__((address_space(1)))
int get_global_id(int index);
/* Test kernel */
__kernel void test(__global float *in, __global float *out) {
int index = get_global_id(0);
out[index] = 3.14159f * in[index] + in[index];
}
then we following the following steps:
clang -mfloat-abi=hard -mfpu=neon -S -emit-llvm -x cl
-I/home/tgall/opencl/SNU/src/compiler/tools/clang/lib/Headers
-I/home/tgall/opencl/SNU/inc -include
/home/tgall/opencl/SNU/inc/comp/cl_kernel.h
/home/tgall/opencl/SNU/tmp2/cl_temp_1.cl -o
/home/tgall/opencl/SNU/tmp2/cl_temp_1.ll
with the resulting cl_temp_1.ll we:
llc /home/tgall/opencl/SNU/tmp2/cl_temp_1.ll
which results in cl_temp_1.s. Then:
clang -c -mfloat-abi=hard -mfpu=neon -o
/home/tgall/opencl/SNU/tmp2/cl_temp_1.o
/home/tgall/opencl/SNU/tmp2/cl_temp_1.s
so now in theory we should have a perflectly good cl_temp_1.o ready for linking.
But first let's get the bits ready that will be built by the
traditional gnu toolschain. We have:
gcc -shared -fPIC -O3 -o /home/tgall/opencl/SNU/tmp2/cl_temp_1_info.so
/home/tgall/opencl/SNU/tmp2/cl_temp_1_info.c
and
gcc -shared -fPIC -march=armv7-a -mtune=cortex-a9 -mfloat-abi=hard
-mfpu=neon -fsigned-char -DDEF_INCLUDE_ARM -I. -I
/home/tgall/opencl/SNU/src/runtime/hal/device/cpu -I
/home/tgall/opencl/SNU/src/runtime/include -I
/home/tgall/opencl/SNU/src/runtime/core -I
/home/tgall/opencl/SNU/src/runtime/core/device -I
/home/tgall/opencl/SNU/src/runtime/hal -I
/home/tgall/opencl/SNU/src/runtime/hal/device -DTARGET_MACH_CPU -O3 -c
/home/tgall/opencl/SNU/src/runtime/hal/device/cpu/hal.c -o
/home/tgall/opencl/SNU/tmp2/hal.o
And here we try to link it all together.
g++ -shared -fPIC -march=armv7-a -mtune=cortex-a9 -mfloat-abi=hard
-mfpu=neon -fsigned-char -DDEF_INCLUDE_ARM -O3 -o
/home/tgall/opencl/SNU/tmp2/cl_temp_1.tkl
/home/tgall/opencl/SNU/tmp2/hal.o
/home/tgall/opencl/SNU/tmp2/cl_temp_1.o
-L/home/tgall/opencl/SNU/lib/lnx_arm
-lsnusamsung_opencl_builtin_lnx_arm -lpthread -lm
and bang we're back to the error I first mentioned:
/usr/bin/ld: error: /home/tgall/opencl/SNU/tmp2/cl_temp_1.tkl uses VFP
register arguments, /home/tgall/opencl/SNU/tmp2/cl_temp_1.o does not
so first obvious question is -mfloat-abi=hard -mfpu=neon correct for clang?
tgall@miranda:~/opencl/SNU/tmp2$ clang --version
clang version 3.3
Target: armv7l-unknown-linux-gnueabihf
Thread model: posix
Thanks for any suggestions!
--
Regards,
Tom
"Where's the kaboom!? There was supposed to be an earth-shattering
kaboom!" Marvin Martian
Tech Lead, Graphics Working Group | Linaro.org │ Open source software
for ARM SoCs
w) tom.gall att linaro.org
h) tom_gall att mac.com
