Since it came up in the toolchain meeting this morning, some links to
issues people are having doing ARM scratchbox-style builds because of
generic linux-user issues:
http://bugs.meego.com/show_bug.cgi?id=10529 # linux-user's mmap
implementation isn't very smart
https://bugs.launchpad.net/qemu/+bug/668799 # qemu locking issues
which can cause build failures (sometimes)
-- PMM
https://blueprints.launchpad.net/ubuntu/+spec/other-linaro-n-cross-compilers:
- wrote patches for creating backports PPA
- each component [1] generates versioned -source binary package
(eglibc-2.12.1-source etc)
- a-c-t-b [2] got "PPA" boolean variable in rules to have one source package
for archive and for backports
- I built a-c-t-b with all components backports from natty in lucid pbuilder
Bugs:
- 684625 - libc6 is compiled for armv5 instead of armv7a
- confirmed, wrote fix, will sent for review and merge
- 683832 - gcc fails to cross compile Qt
- confirmed in maverick for cross gcc 4.4/4.5
- need to check with fixed (bug 684625) toolchain
- FTFBS of armel-cross-toolchain-base 1.53/natty
- issue is lack of LTO plugin built in gcc/stage2
- have first patches for it, need to test
1. component = eglibc, gcc-4.4/4.5, binutils, linux
2. a-c-t-b = armel-cross-toolchain-base
Regards,
--
JID: hrw(a)jabber.org
Website: http://marcin.juszkiewicz.com.pl/
LinkedIn: http://www.linkedin.com/in/marcinjuszkiewicz
== GCC related ==
* PR44557, Thumb-1 ICE: originally thought a fix of constraint will
work, however after simplifying the testcase, received another ICE in
postreload, due to a load of IP, which is not permitted in Thumb-1.
Looking at some reload internals as part of fixing this.
* PR45416, ARM code generation regression. First fix from last week hit
an assert FAIL in the alias-oracle due to ARRAY_REFs not being handled
there. Also, further found some expand code quality regressions due to
this change. Turned to a more conservative fix by adding the related TER
substitution to expr.c:do_store_flag(), which produced more focused
results. However, 32-bit x86 slightly regressed in the same flag storing
code (did not use the 'testl' insn after the change). Still WIP.
* PR46667, submitted a section type conflict bug fix upstream, see
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00137.html , which
supposedly fixes the upstream ARM-Linux C++ build. Jan Hubicka later
gave another fix, so still in discussion.
* PR45886, this PR is call for backporting the __ARM_PCS* preprocessor
symbols to gcc-4_5-branch. Submitted a mail to ask for approval, no
response.
== libffi VFP hard-float ==
* PR46508, libffi VFP assembly error. I missed this earlier due to using
a compiler configured with --with-fpu=vfp. Submitted assembly fix to add
the needed FPU directives. Committed to upstream trunk.
== This week ==
* Hope to wrap up the above in-progress PRs, as well as continue to look
at other PRs of interest.
* LP #685534 popped up on Sunday, and manifests on upstream trunk too.
Add this to queue.
* Think about GCC performance opportunities (Linaro)
== Linaro GCC ==
* Reproduce regression of my ldm/stm backport on 4.5, which is caused by
the other two merged patches in ifcvt.c. Fix them. Propose merge
request again. Learn how to sync/merge changes from one branch to the
other branch.
* Fix VFP_D0_D7 handling in predicate vfp_register_operand. Approved
and committed upstreams.
* Test new regrename improvement patch on x86_64, and measure
effectiveness of it on ARM. Code size of bash-3.2 is reduced 0.2% with
option "-march=armv7a -mthumb -O2 -frename-registers". Eric B. is
almost OK with this patch except some wording in comments.
== Linaro GDB ==
As discussed in UDS, I'll move to GDB work for gdb correctness.
http://ex.seabright.co.nz/helpers/planner#tr-toolchain-gdb-correctness
In this month, I'll focus on GDB testsuite failures fixing.
* Analyze LP:615978, failures in gdb.base/annota3.exp.
Signal is not delivered to child while software single-stepping. The
same as LP:649121.
* Fix failure in gdb.xml/tdesc-regs.exp. LP:685494
It is caused by a target triplet matching error, when target is set to
"armv7l-linux-gnueabi". Target triplet matching in test cases should be
changed. Patch is being reviewed in upstreams.
* LP:616000 failures caused by -fstack-protector.
Homework to understand frame-related code in GDB. Got some big picture
of usage of some key data structures inside GDB on frame. Compared with
prologue with and without stack-protector, find some difference there.
Still no clue on how to educate GDB to identify whether stack-protector
is turned on or off.
* Fix one failure in printcmds.exp. LP:685702
This test case on 7.2 branch is a little bit out of date, compared with
GDB trunk. Backport one patch on trunk to 7.2 branch can fix this
problem. Backport patch is being reviewed in upstreams.
* Neon registers in kernel dump file. LP:615972
Ask Linaro kernel WG to see how to move forward on this. Discussion is
still ongoing.
== This Week ==
* Report the rest of GDB testsuite failures.
* Pick up some of them, and fix.
* Pass gcc patches in my queue one by one to gcc-patches to review.
--
Yao (齐尧)
RAG:
Red:
Amber:
Green:
Milestones:
| Planned | Estimate | Actual |
finish virtio-system | 2010-08-27 | postponed | |
get valgrind into linaro PPA | 2010-09-15 | 2010-09-28 | 2010-09-28 |
complete a qemu-maemo update | 2010-09-24 | 2010-09-22 | 2010-09-22 |
finish testing PCI patches | 2010-10-01 | 2010-10-22 | 2010-10-18 |
Progress:
* merge-correctness-fixes:
** Nathan Froyd (CodeSourcery) has reviewed a lot of
my ARM patches. Most were OK, one or two needed tweaking
We seem to have come to agreement on how best to treat
the API between qemu and the softfloat library, and I
have a V2 patchset ready to mail as soon as Nathan has
commented on the final patch.
** posted a patch to rename a very misleading _is_nan()
function
** identified list of correctness patches in meego and
samsung trees and issues noted within ARM
** qemu: posted patch to remove an unused function
** started looking at the first patch in the meego tree,
which fixes VQSHL. I have already discovered a bug in
this insn not covered by the meego patch...
Meetings: toolchain, PD update, ARM 20th birthday party
Plans:
- qemu consolidation
Issues:
* Locking in qemu is definitely insufficient, especially
(but not exclusively) when running multi-threaded
programs in linux-user mode.
https://bugs.launchpad.net/qemu/+bug/668799
has an example problem and some discussion; I'm hoping
some other qemu developers have an opinion, but the
nicest approach IMHO would involve fairly invasive
changes to how qemu implements interrupting a cpu
which is executing TCG code.
Not sure where this should sit in the priority list.
Things of note:
- there has been some discussion of broadening the "KVM Forum"
conference to include other virtualisation related topics including
Xen and also the TCG aspects of Qemu. Still all up in the air but
possibly colocated with LinuxCon in Vancouver in August. See:
http://www.linux-kvm.org/page/KVM_Forum_2011
Absences: (complete to end of 2010)
Fri 17 Dec - Tue 4 Jan inclusive.
2011: Dallas Linaro sprint 9-15 Jan. Holiday 22 Apr - 2 May.
== This week ==
* Looked at a generic bug in GAS's handling of ifuncs. Sent a patch upstream:
http://sourceware.org/ml/binutils/2010-11/msg00495.html
Alan quite reasonably wanted me to test on a variety of targets. For want
of anything better, I wrote a script to test Alan's list of 118 targets.
Tests went OK, patch committed upstream.
* Wrote more IFUNC tests. Found another problem (as yet unresolved).
* Looked at vector stuff, but nothing tangible yet.
(I also had to spend some time on other IBM things, sorry.)
== Next week ==
* Away Monday and Tuesday.
* More STT_GNU_IFUNC and vectors.
Richard
* Benchmarking of simple package builds with various string routine
versions; not finding enough difference in the noise to make any large
conclusions
* Looking at the string routine behaviour with perf to see where the time
is going
- getting hit by the Linaro kernels on silverbell missing Perf
enablement in the config
- Useful amount of time does seem to be spent outside the main 'fast
aligned' chunks of code
- pushing/popping registers does seem to be pretty expensive
* Started looking at libffi and hard float
- Started writing a spec
https://wiki.linaro.org/WorkingGroups/ToolChain/Specs/LibFFI-variadic
- It's going to need an API change to libffi, although the change
shouldn't break any existing code on existing platforms where they work.
* Helping with the image testing
Dave
Hi,
* got llvm+clang working on ARM:
https://wiki.linaro.org/KenWerner/Sandbox/HowToBuildToolchainComponents#llv…
* checked whether llvm inlines the __sync_* builtins on ARM or not:
https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations#LLVM
* developed a patch for #681138 (tested with current gcc-linaro)
* spent some time for bootstrapping the GCC trunk in order to test and post
that patch on the ml but wasn't successful
(finally ran into the issues discussed at #659713)
* did some verification work on #674090
* preparing to work on the "investigate current developer tools" item
Regards
Ken
Hi there. Currently you can't use NEON instructions in inline
assembly if the compiler is set to -mfpu=vfp such as Ubuntu's
-mfpu=vfpv3-d16. Trying code like this:
int main()
{
asm("veor d1, d2, d3");
return 0;
}
gives an error message like:
test.s: Assembler messages:
test.s:29: Error: selected processor does not support Thumb mode `veor d1,d2,d3'
The problem is that -mfpu=vfpv3-d16 has two jobs: it tells the
compiler what instructions to use, and also tells the assembler what
instructions are valid. We might want the compiler to use the VFP for
compatibility or power reasons, but still be able to use NEON
instructions in inline assembler without passing extra flags.
Inserting ".fpu neon" to the start of the inline assembly fixes the
problem. Is this valid? Are assembly files with multiple .fpu
statements allowed? Passing '-Wa,-mfpu=neon' to GCC doesn't work as
gas seems to ignore the second -mfpu.
What's the best way to handle this? Some options are:
* Add '.fpu neon' directives to the start of any inline assembly
* Separate out the features, so you can specify the capabilities with
one option and restrict the compiler to a subset with another.
Something like '-mfpu=neon -mfpu-tune=vfpv3-d16'
* Relax the assembler so that any instructions are accepted. We'd
lose some checking of GCC's output though.
-- Michael
- Continued looking into NEON special loads and stores.
- Benchmarks: concentrated on EEMBC Telecom:
- autcor gets vectorized
- viterbi, besides strided data accesses, needs to sink conditional
stores to allow if-conversion and make the main loop vectorizable.
Since the potential here is 4x, I think it's worthwhile to work on
this.
- conven, fbital also have control-flow issue, but much more
complicated than viterbi
- fft has a problem with loop count, I would like to investigate
this a bit more
- diffmeasure doesn't seem to have vectorization potential
- Fixed GCC PR 46663 on trunk, testing the fix for 4.3, 4.4, 4.5.
Hi,
Here's a work-in-progress patch which fixes many execution failures
seen in big-endian mode when -mvectorize-with-neon-quad is in effect
(which is soon to be the default, if we stick to the current plan).
But, it's pretty hairy, and I'm not at all convinced it's not working
"for the wrong reason" in a couple of places.
I'm mainly posting to gauge opinions on what we should do in big-endian
mode. This patch works with the assumption that quad-word vectors in
big-endian mode are in "vldm" order (i.e. with constituent double-words
in little-endian order: see previous discussions). But, that's pretty
confusing, leads to less than optimal code, and is bound to cause more
problems in the future. So I'm not sure how much effort to expend on
making it work right, given that we might be throwing that vector
ordering away in the future (at least in some cases: see below).
The "problem" patterns are as follows.
* Full-vector shifts: these don't work with big-endian vldm-order quad
vectors. For now, I've disabled them, although they could
potentially be implemented using vtbl (at some cost).
* Widening moves (unpacks) & widening multiplies: when widening from
D-reg to Q-reg size, we must swap double-words in the result (I've
done this with vext). This seems to work fine, but what "hi" and "lo"
refer to is rather muddled (in my head!). Also they should be
expanders instead of emitting multiple assembler insns.
* Narrowing moves: implemented by "open-coded" permute & vmovn (for 2x
D-reg -> D-reg), or 2x vmovn and vrev64.32 for Q-regs (as
suggested by Paul). These seem to work fine.
* Reduction operations: when reducing Q-reg values, GCC currently
tries to extract the result from the "wrong half" of the reduced
vector. The fix in the attached patch is rather dubious, but seems
to work (I'd like to understand why better).
We can sort those bits out, but the question is, do we want to go that
route? Vectors are used in three quite distinct ways by GCC:
1. By the vectorizer.
2. By the NEON intrinsics.
3. By the "generic vector" support.
For the first of these, I think we can get away with changing the
vectorizer to use explicit "array" loads and stores (i.e. vldN/vstN), so
that vector registers will hold elements in memory order -- so, all the
contortions in the attached patch will be unnecessary. ABI issues are
irrelevant, since vectors are "invisible" at the source code layer
generally, including at ABI boundaries.
For the second, intrinsics, we should do exactly what the user
requests: so, vectors are essentially treated as opaque objects. This
isn't a problem as such, but might mean that instruction patterns
written using "canonical" RTL for the vectorizer can't be shared with
intrinsics when the order of elements matters. (I'm not sure how many
patterns this would refer to at present; possibly none.)
The third case would continue to use "vldm" ordering, so if users
inadvertantly write code such as:
res = vaddq_u32 (*foo, bar);
instead of writing an explicit vld* intrinsic (for the load of *foo),
the result might be different from what they expect. It'd be nice to
diagnose such code as erroneous, but that's another issue.
The important observation is that vectors from case 1 and from cases 2/3
never interact: it's quite safe for them to use different element
orderings, without extensive changes to GCC infrastructure (i.e.,
multiple internal representations). I don't think I quite realised this
previously.
So, anyway, back to the patch in question. The choices are, I think:
1. Apply as-is (after I've ironed out the wrinkles), and then remove
the "ugly" bits at a later point when vectorizer "array load/store"
support is implemented.
2. Apply a version which simply disables all the troublesome
patterns until the same support appears.
Apologies if I'm retreading old ground ;-).
(The CANNOT_CHANGE_MODE_CLASS fragment is necessary to generate good
code for the quad-word vec_pack_trunc_<mode> pattern. It would
eventually be applied as a separate patch.)
Thoughts?
Julian
ChangeLog
gcc/
* config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Allow changing mode
of vector registers.
* config/arm/neon.md (vec_shr_<mode>, vec_shl_<mode>): Disable in
big-endian mode.
(reduc_splus_<mode>, reduc_smin_<mode>, reduc_smax_<mode>)
(reduc_umin_<mode>, reduc_umax_<mode>)
(neon_vec_unpack<US>_lo_<mode>, neon_vec_unpack<US>_hi_<mode>)
(neon_vec_<US>mult_lo_<mode>, neon_vec_<US>mult_hi_<mode>)
(vec_pack_trunc_<mode>, neon_vec_pack_trunc_<mode>): Handle
big-endian mode for quad-word vectors.
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
Reviewed Yao's patch for AND optimization. Some back on forth on the
best way to tackle this problem.
LP:663939 - thumb2 constant loading
- backported my patches to GCC 4.5
- awaiting review
LP:595479 - .eh_frame broken.
- Discovered this problem had been fixed (with Thomas' patch) since
August, and has also been fixed upstream, albeit with an alternative
patch. Nothing to do here.
LP:641379 - bitfields poorly optimized.
- analysed the problem. The code in cse.c that is supposed to fix this
does not recognise the case.
- created a patch and tested it for both GCC 4.6 and 4.5.
- awaiting review
LP:674146 - dpkg segfault.
- started looking at this, but Chung-Lin took it first.
While trying to reproduce lp:674146, I discovered that my IGEPv2 had a
corrupted rootfs, again. I only fixed it last week, so I looked into it
more deeply. It seems the SD card has developed at least one bad block.
Reformatted, scanned and reinstalled the files from backup. I think the
problem was caused by the daily apt package download (it was always
those files that were corrupt), so I've disabled that. I've also
disabled access-time-stamps. If it happens again I will have to consider
using a different underlying filesystem format.
LP:643479 / CS Issue:8610 - Multiply and accumulate optimization
- created patches for both issues.
- both were machine description subtleties.
- backported the patches to 4.5
- the patches apply and work fine, but ...
- found an extra problem with redundant moves
- awaiting review
GCC 4.6
- Created a new Launchpad series and branch to track GCC 4.6 development.
- Set up the CS internal build config.
- Tried to build the latest checkout and failed
- glibc problem still unfixed - Jie has reported it now.
- libquadmath build fails
Merged FSF GCC trunk (pre-4.5.2) into Linaro GCC 4.5 tree.
Merged the outstanding Launchpad merge requests into GCC 4.5. The
testing showed regressions, so I backed out most of the merges and did
them in smaller batches. Chung-Lin and Richard's patches passed the
testing, so that leaves Yao's as the problem patch. I didn't get time to
test this assertion this week.
----------------------------------
Next week: Vacation.
Andrew Stubbs wrote:
> * Instruction set coverage.
> - Are there any ARM/Thumb2 instructions that we are not taking
> advantage of? [2]
> - Do we test that we use the instructions we do have? [3]
There is no general frame work to test instruction set coverage. The only
way to find out, really, is to create some test cases where you expect
the compiler to produce a certain insn.
Is there a list of all ARM/Thumb2 instructions and the ones implemented in
the GCC ARM machine descriptions?
> * Constant pools
> - it might be a very handy space optimization to have small
> functions share one constant pool, but the way the passes work one
> function at a time makes this hard. (LP:625233)
There are also passes working on the entire program, or a partition.
Isn't it more a question of how to group and process functions that are
candidates for sharing a constant pool with a neighbor?
Are there algorithms for this kind of pool sharing in the academic
or ARM-specific literature?
Other suggestions for the discussion:
* Better use of conditional execution.
- No idea how much this really helps for ARM, but there are bug
reports about missed opportunities from time to time, so...
- How to model conditional execution before register allocation?
- How exploit opportunities better in GCC (ifcvt is inadequate
and too late in the pipeline).
- Also look at LLVM here, it appears to have a better cost model
for if-conversion than GCC (taking into account a target-dependent
branch misprediction
penalty, for example).
* Basic block re-ordering for speed/size.
- The existing basic block reordering pass in GCC implements only
a reordering strategy for speed.
- The pass does not run at all for functions optimized for size.
* Comparing ARM cost models and param settings to x86_64
- Compare, for some set of functions/benchmarks, the results of
estimate_num_insns, estimate_operator_cost, and
estimate_move_cost, between ARM and x86_64. Rationalize or fix
any significant differences. See whether heuristics based on
these functions require tuning for ARM.
- Go through params.def and see if there are further ARM tuning
opportunities. There are more than 100 DEFPARAMs and many of
them guide heuristics but have only been tuned on x86_64.
(There is set_default_param_value, but most backends do not
change the defaults.)
Hoping this is helpful,
Ciao!
Steven
David G. requested a few packages installed on silverbell today (the
quad-A9 VE porter machine we host in the datacenter). We got dchroots
instead:
----- Forwarded message from LaMont Jones via RT <rt(a)admin.canonical.com> -----
Date: Fri, 26 Nov 2010 21:02:22 +0000
Subject: [rt.admin.canonical.com #42662] Simple package installs on silverbell
On Fri Nov 26 17:08:28 2010, kiko(a)canonical.com wrote:
> Hi there,
>
> Could we get installed on silverbell:
>
> build-essential
> debhelper
> fakeroot
>
> And could we get deb-src's added to sources.list and do an apt-get
> update to allow us to apt-get source certain packages? This is for
> simple compilation benchmarks. Thanks!
Dchroot environments have been created on silverbell for both maverick
and natty. Within the chroot, you can sudo apt-get install to install
packages. apt-get update/dist-upgrade and installs that cause package
removal will require a GSA to do them.
To build for maverick: dchroot -c maverick (and then build however you want...)
lamont
----- End forwarded message -----
--
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Linaro Engineering VP | [ +1] 612 216 4935 | http://async.com.br/~kiko
Hi,
* the ARM __sync_* glibc-ports patch was accepted upstream
* posted proposal for consolidating sync primitives but stdatomic seems to be
the future
* used my small gcc testsuite patch to verify __sync_* support of the gcc-
linaro
* created:
https://wiki.linaro.org/WorkingGroups/ToolChain/AtomicMemoryOperations
* looked into GOMP support on ARM:
- #pragma omp atomic results in proper asm code (dmb, ldrex, strex, dmb)
- #pragma omp flush results in a DMB instruction
- #pragma omp barrier results to a call to GOMP_barrier (I'm not sure if
this is the desired behavior)
* started to look into #681138
Regards
Ken
