Hi there. I've had a few questions recently about how to build a
cross compiler, so I took a stab at writing the steps down in a
Makefile. See:
https://code.launchpad.net/~michaelh1/+junk/cross-build
Hopefully it's easy to follow. It uses a binary sysroot and gives you
vanilla binutils 2.20 and Linaro GCC 2010.11 in a good enough way that
you can cross-compile for Maverick. The script is minimal and trades
readability for flexibility.
Note that Marcin's cross compiler packages or the Embedian toolchains
are a better way to go, but if you want to see the steps involved
check out the script.
Marcin or Matthias, would you mind reviewing it?
-- Michael
Hi,
- the struggle with the board took a lot of time
- continued to investigate special loads/stores
- looked for benchmarks:
EEMBC Consumer filters rgbcmy and rgbyiq should be vectorizable
once vld3, vst3/4 are supported
EEMBC Telecom viterbi is supposed to give 4x on NEON once
vectorized (according to
http://www.jp.arm.com/event/pdf/forum2007/t1-5.pdf slide 29). My old
version of viterbi is not vectorizable because of if-conversion
problems. I'd be really happy to check the new version (it is supposed
to be slightly different).
Looking into other EEMBC benchmarks.
FFMPEG http://www.ffmpeg.org/ (got this from Rony Nandy from
User Platforms). It contains hand-vectorized code for NEON.
Investigating.
I am probably taking a day off on Sunday.
Ira
This wiki page came up during the toolchain call:
https://wiki.linaro.org/Internal/People/KenWerner/AtomicMemoryOperations/
It gives the code generated for __sync_val_compare_and_swap
as including a push {r4} / pop {r4} pair because it uses too many
temporaries to fit them all in callee-saves registers. I think you
can tweak it a bit to get rid of that:
# int __sync_val_compare_and_swap (int *mem, int old, int new);
# if the current value of *mem is old, then write new into *mem
# r0: mem, r1 old, r2 new
mov r3, r0 # move r0 into r3
dmb sy # full memory barrier
.LSYT7:
ldrex r0, [r3] # load (exclusive) from memory pointed to
by r3 into r0
cmp r0, r1 # compare contents of r0 (mem) with r1
(old) -> updates the condition flag
bne .LSYB7 # branch to LSYB7 if mem != old
# This strex trashes the r0 we just loaded, but since we didn't take
# the branch we know that r0 == r1
strex r0, r2, [r3] # store r2 (new) into memory pointed to
by r3 (mem)
# r0 contains 0 if the store was
successful, otherwise 1
teq r0, #0 # compares contents of r0 with zero ->
updates the condition flag
bne .LSYT7 # branch to LSYT7 if r0 != 0 (if the
store wasn't successful)
# Move the value that was in memory into the right register to return it
mov r0, r1
dmb sy # full memory barrier
.LSYB7:
bx lr # return
I think you can do a similar trick with __sync_fetch_and_add
(although you have to use a subtract to regenerate r0 from
r1 and r2).
On the other hand I just looked at the gcc code that does this
and it's not simply dumping canned sequences out to the
assembler, so maybe it's not worth the effort just to drop a
stack push/pop.
-- PMM
== Linaro GCC ==
* Finished testing patch for lp675347 (QT inline-asm atomics), and
send upstream for comments (no response yet). Suggested reverting a
patch (which enabled -fstrict-volatile-bitfields by default on ARM)
locally for Ubuntu in the bug log.
* Continued working on NEON quad-word vectors/big-endian patch. This
turned out to be slightly fiddlier than I expected: I think I now have
semantics which make sense, though my patch requires (a) slight
middle-end changes, and (b) workarounds for unexpected combiner
behaviour re: subregs & sign/zero-extend ops. I will send a new version
of the patch to linaro-toolchain fairly soon for comments.
Hello,
I have a question about cbnz/cbz thumb-2 instruction implementation in
thumb2.md file:
I have an example where we jump to a label which appears before the branch;
for example:
L4
...
cmp r3, 0
bne .L4
It seems that cbnz instruction should be applied in this loop; replacing
cmp+bne; however, cbnz fails to be applied as diff = ADDRESS (L4) - ADDRESS
(bne .L4) is negative and according to thumb2_cbz in thumb2.md it should
be 2<=diff<=128 (please see snippet below taken from thumb2_cbz).
So I want to double check if the current implementation of thumb2_cbnz
in thumb2.md needs to be changed to enable it.
The following is from thumb2_cbnz in thumb2.md:
[(set (attr "length")
(if_then_else
(and (ge (minus (match_dup 1) (pc)) (const_int 2))
(le (minus (match_dup 1) (pc)) (const_int 128))
(eq (symbol_ref ("which_alternative")) (const_int 0)))
(const_int 2)
(const_int 8)))]
Thanks,
Revital
== This week ==
* More ARM testing of binutils support for STT_GNU_IFUNC.
* Implemented the GLIBC support for STT_GNU_IFUNC. Simple ARM testcases
seem to run correctly.
* Ran the GLIBC testsuite -- which includes some ifunc coverage --
but haven't analysed the results yet.
* Started looking at Thumb for STT_GNU_IFUNC. The problem is that
BFD internally represents Thumb symbols with an even value and
a special st_type (STT_ARM_TFUNC); this is also the old, pre-EABI
external representation. We need something different for STT_GNU_IFUNC.
* Tried making BFD represent Thumb symbols as odd-value functions
internally. I got it to "work", but I wasn't really happy with
the results.
* Looked at alternatives, and in the end decided that it would be
better to have extra internal-only information in Elf_Internal_Sym.
This "works" too, and seems cleaner to me. Sent an RFC upstream:
http://sourceware.org/ml/binutils/2010-11/msg00475.html
* Started writing some Thumb tests for STT_GNU_IFUNC.
* Investigated #618684. Turned out to be something that Bernd
had already fixed upstream. Tested a backport.
== Next week ==
* More IFUNC tests (ARM and Thumb, EGLIBC and binutils).
Richard
== Linaro and upstream GCC ==
* LP #674146, dpkg segfaults during debootstrap on natty armel: analyzed
and found this should be a case of PR44768, backported mainline revision
161947 to fix this.
* LP #641379, bitfields poorly optimized. Discussed some with Andrew Stubbs.
* GCC bugzilla PR45416: Code generation regression on ARM. Been looking
at this regression, that started from the expand from SSA changes since
4.5-experimental. The problem seems to be TER not properly being
substituted during expand (compared to prior "convert to GENERIC then
expand"). I now have a patch for this, which fixes the PR's testcase,
but when testing current upstream trunk, hit an assert fail ICE on
several testcases in the alias-oracle; it does however, test without
regressions on a 4.5 based compiler. I am still looking at the upstream
failures.
== This week ==
* Continue with GCC issues and PRs.
* Think about GCC performance opportunities (Linaro)
== Last Week ==
* Started writing libunwind support for ARM-specific unwinding, but
realized that the native ARM toolchain may be causing problems. Spent time
trying to isolate the issues, but haven't found the culprit yet.
* Began to consider the possibility of developing an ARM-specific
unwinding library which would integrate into libunwind (and be reusable
elsewhere). Basically, the ARM.ex{idx,tbl} sections are unique to ARM.
* Looked at other applications where unwinding functionality already
exists to see how ARM unwinding is done (e.g. GDB).
Could/should that functionality be replaced with calls to libunwind (or
to the aforementioned ARM-specific helper library)?
== This Week ==
* Continue to implement ARM-specific unwinding in libunwind.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
== Linaro GCC ==
* LP:634738: Firstly, fix this in combiner. Try the other approach
(without changes to arm.md) suggested by Andrew S, to fix
arm_gen_constant in some cases to generate lsl/lsr ranther loading
constant. Some piece of code in arm.c was written in 1998, hard to
understand with few comments. During this, find some lsl/lsr can be
replaced by ubfx. Use gen_extzv_t2 when arm_arch_thumb2 is true to
transform lsl + lsr to ubfx. Two patches are ready.
* LP:633243: Got build failures on FSF trunk for
arm-none-linux-gnueabi. Test patch on FSF trunk 2010-10-21. No regression.
* LP:638935: predicate "vfp_register_operand" should return true for
VFP_D0_D7_REGS registers. Fixed.
predicates {store,load}_multiple_operation assumes mode is SImode, and
size of data is 4. Fix them to accept multiple VFP operations. Write
three new test cases for stm/fldm/fstm pattern. Test patch on FSF trunk
2010-10-21. No regression.
* SMS on thumb2. Discussed with Revital Eres back and forth on doloop
pattern for thumb2. doloop pattern is not recognized so far on thumb2.
Revital has a fix to thumb2_cbz pattern. After this fix, doloop
pattern should be recognized.
* Ping ARM fix PR45701 in gcc-patches for the fifth time. Still no reply.
== This Week ==
* Look at regressions of ldm/stm backport on Linaro GCC 4.5.
* Internal review of patch to LP:638935
* Try SMS on thumb2 for EEMBC, if Revital's thumb2_cbz pattern fix is
accepted by upstreams.
--
Yao (齐尧)
Hi there. Our Versatile Express has been installed in the data centre
and is available for use. See:
https://wiki.linaro.org/WorkingGroups/ToolChain/Hardware
for the details. If you're a member of the Toolchain WG then you
should already have an account.
Dave is currently using this machine for benchmarking. Until we get
more hardware, please use IRC or email to manage access.
-- Michael