Hi,
I'm working on the libatomic-ops (part of the Boehm gc) AArch64 support,
I mainly use GCC's __atomic builtins to do this, but in our 4.7 version
they don't use the load acquire / store release instructions now available
in the ARMv8 ISA. These instructions are used in the mainline GCC
(in atomic.md) but not in their exclusive form, I understand that it should
be due to the performance penalty, but I want your feeling on that point
as I don't find the ARMv8 ISA really clear.
If we want to implement an atomic load acquire, is
LDAR x1, [x0]
sufficient, or do we have to write it like that :
L: LDAXR x0, [x3]
STEX x1, x0, [x3]
CBZ x0, L1
Thanks
Yvan
All,
[Editiorial: Michael & I discussed making what we do as a working
group more visible at Connect. One thing we discussed was making our
meeting minutes more visible by emailing actions out after each
meeting. This will be part of the job of the 'minuter' - a job I plan
to spread around as I am useless at it whilst also running a call -
more info on the Wiki:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings]
The minutes of the performance call held on 27 November 2012 can be found at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-11-27
In summary the actions from the meting are:
* mgrettondann split LRA blueprint
* Christophe to update Hot/Cold partitioning bugzilla
* mgrettondann: benchmark on Hold/Cold partitioning
* Michael to log a ticket to improve reporting of benchmarks when the
run complete.
* Ramana to log EEMBC failure with Hot/Cold partitioning into bugzilla.
* Christophe to backport bswap16 builtin, except for the testcase
which fails in one of our configurations (Thumb1 + hard FP ABI)
The next performance call will be on 11 December 2012 and the agenda
can be found at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-12-11
Thanks,
Matt
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
The Linaro Toolchain Working Group is pleased to announce the 2012.11
release of the Linaro Toolchain Binaries, a pre-built version of
Linaro GCC and Linaro GDB that runs on generic Linux or Windows and
targets the glibc Linaro Evaluation Build.
Uses include:
* Cross compiling ARM applications from your laptop
* Remote debugging
* Build the Linux kernel for your board
What's included:
* Linaro GCC 4.7 2012.11
* Linaro GDB 7.5 2012.09
* A statically linked gdbserver
* A system root
* Manuals under share/doc/
The system root contains the basic header files and libraries to link
your programs against.
The Linux version is supported on Ubuntu 10.04.3 and 12.04, Debian
6.0.2, Fedora 16, openSUSE 12.1, Red Hat Enterprise Linux Workstation
5.7 and later, and should run on any Linux Standard Base 3.0
compatible distribution. Please see the README about running on
x86_64 hosts.
The Windows version is supported on Windows XP Pro SP3, Windows Vista
Business SP2, and Windows 7 Pro SP1.
The binaries and build scripts are available from:
https://launchpad.net/linaro-toolchain-binaries/trunk/2012.11
Need help? Ask a question on https://ask.linaro.org/
Already on Launchpad? Submit a bug at
https://bugs.launchpad.net/linaro-toolchain-binaries
On IRC? See us on #linaro on Freenode.
Other ways that you can contact us or get involved are listed at
https://wiki.linaro.org/GettingInvolved.
Summary:
* Investigate shrink-wrap result.
* Prepare for Linaro toolchain binary release, script merge and aarch64 test.
Details:
1. Investigate shrink-wrap result of function Ray_In_Bound. By
default, ARM/MIPS/PPC/X86 toolchain can not shrink-wrap the function.
For ARM, there is copy "r6 = r1" which blocks the optimization. By
hacking the assemble code, I got ~3% performance improvement for
453.povray benchmark.
2. Setup AARCH64 simulation environment by following
http://www.linaro.org/engineering/armv8.
3. Write scripts to collect branch cost performance. It will take
weeks to get all the benchmark results.
4. Smoke test Linaro toolchain binaries 2012.11 release.
5. Try export crosstool-ng trunk to a bzr project. bzr fast-import
always fail on Ubuntu 10.04, but it works on 12.04.
6. RM toolchain related work.
Plans:
* Collect performance data for branch cost tuning.
* Linaro binary toolchain 2012.11 release.
* Verify shrink-wrap bugs.
Best regards!
-Zhenqiang
== Progress ==
* Turn off 64-bits bitops in Neon: initial implementation under
benchmarking.
Currently it modifies the handling of: add, sub, and, or, xor, shifts,
not. In some case the generated code is quite larger, so it will careful
benchmarking.
* Started looking at "disable peeling" blue-print. Reading GCC source code
to get more familiar with that area.
* Internal support
== Blueprints ==
Initial Current Actual
initial-aarch64-backport 31 Oct 2012 30 Nov 2012
aarch64-baremetal-testing 31 Oct 2012 30 Nov 2012
fix-gcc-multiarch-testing 31 Dec 2012 31 Dec 2012
backport-fma-intrinsic 31 Dec 2012 31 Dec 2012
fused-multiply-add-support 31 Dec 2012 31 Dec 2012
gcc-investigate-lra-for-arm 31 Dec 2012 31 Dec 2012
== Progress ==
* Admin
* Interviewing
* Investigate patches for literal pool layout bug
* Took longer than expected as the 'simple' fix is wrong due to GCC not
knowing how large instructions actually are.
* Patch posted upstream
* Post triplet backport patches upstream
* Other bug issues
* Including an issue running SPEC2K on x86 with recent trunk
== Next Week ==
* Run HOT/COLD partitioning benchmarks
* Analyse ARM results
* On x86_64 to see what the actual benefit we could get
* initial-aarch64-backport & aarch64-baremetal-testing
* Finish documentation
* gcc-investigate-lra-for-arm
* Analyse benchmarks
* fix-gcc-multiarch-testing
* Come up with strawman proposal for updating testsuite to handle
testing with varying command-line options.
== Future ==
* backport-fma-intrinsic & fused-multiply-add-support
* Backport patches once fix-gcc-multiarch-testing has been done.
--
Matthew Gretton-Dann
Linaro Toolchain Working Group
matthew.gretton-dann(a)linaro.org
Hi,
I try ARM, MIPS, PowerPC and X86 on povray benchmark. No one can
shrink-wrap function Ray_In_Bound.
Here is:
bool Ray_In_Bound (RAY *Ray, OBJECT *Bounding_Object)
{
...
for (Bound = Bounding_Object; Bound != NULL; Bound = Bound->Sibling)
{...}
return (true);
}
For ARM O2/O3, "Bound" is allocated to "r6" during ira. So there is copy
r6 = r1 before
testing Bound != NULL
The copy (using r6) blocks the shrink-wrap optimization since r6
should be saved. Need enhance shrink-wrap to handle this case.
Overall, for povray benchmark,
54 functions are shrink-wrapped for ARM;
59 functions are shrink-wrapped for X86;
25 functions are shrink-wrapped for MIPS;
26 functions are shrink-wrapped for PowerPC.
Thanks!
-Zhenqiang
On 15 November 2012 01:58, 남관우 <kw46.nam(a)samsung.com> wrote:
>
> Hi,
>
>
>
> As your guide, i tried to build again.
>
>
>
> without : -mapcs -fno-common -fstack-protector --param==ssp=buffer-size=4
>
>
> and -fPIC instead of -fpic
>
>
>
> But it is failed with same the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03)
>
>
>
> Thank you,
>
> Kwanwoo Nam.
>
>
>
> ------- Original Message -------
>
> Sender : 남관우<kw46.nam(a)samsung.com> S4(선임)/선임/SLP개발그룹(무선)/삼성전자
>
> Date : 2012-11-14 21:45 (GMT+09:00)
>
> Title : Re: Re: Re: unexpected reloc type 0x03 error with gcc-4.6.4 (2012.10 version)
>
>
>
> Hi,
>
>
>
> Here is our LDFLAGS.
>
> -Wl,--rpath=/usr/lib -Wl,--as-needed
>
>
>
> And i try to build with your guide.
>
> without : -mapcs -fno-common
> and -fPIC instead of -fpic
>
>
>
> But it is failed with same the message. (/usr/lib/libnfc-common-lib.so.1: unexpected reloc type 0x03)
Ta. I'm afraid we don't have enough information to solve this.
Could you please send a full build log and we can go from there.
gzipped on a public server is best.
-- Michael
