Hi,
I was just wondering if anyone knows of any current or future dependencies with the Linaro toolchain (2011.11) and the Linaro release of GDB and the Linux Kernel?
Is it considered safe to use the toolchain with the upstream releases of GDB and the Kernel, assuming that the versions of each are suitably compatible?
Or are there potential dependencies on work that has been done in the toolchain? For example, new instructions supported in the compiler/assembler, or enhancements to the kernel/runtime library on the Linaro branch that would depend on them being in sync.
Thanks,
Dave.
Hi,
OpenEmbedded-Core:
* the CSL 2011.03 recipe works with localization support disabled
* got the OE-Core sato image to built (~250 source packages)
* also built the Qt4 demo image (~100 source packages) to stress the
C++ part of the toolchain
* both are booting using qemu and seem to work just fine.
* all of the Linaro members approved the request to contribute to
OpenEmbedded
* started to post patches onto the mailing list
* briefly looked at the Linaro binary toolchain
* the most recent one is dynamically linked
* while the old one has old binutils (.21) that causes issue with
--gc-sections
* Currently the build is using the OE qemuarm machine configuration that
uses a Yocto kernel and targets armv5te. This is something I'd like to
look at too.
Regards
Ken
Continued work on 64-bit shifts.
- Improved 64-bit shifts without NEON (should benefit all cases).
- Fixed bugs in constant shift code.
- Rewrote 64-bit neon patch to take advantage of the new non-neon
code, in the fall-back case.
- Titied up the code, in general.
- Rewrote SImode shift amount patch for new neon patches.
The code produced now seems pretty good, but it still seems to choose
which mode to use slightly haphazardly. The next step is to figure that
out and benchmark the results.
Had a few more attempts at getting the LAVA system to do something
useful for me. I'm getting closer, but keep hitting new problems. Some
of them my fault, and some are bugs in the system. Paul Larson has been
very kindly helping me out and swatting the bugs.
Didn't get much further with benchmarking for the generic tuning. This
has been put on the back-burner while I work on the Neon shifts, and my
test runs on my IGEPv2 A8 board have all been interrupted by power cuts
or rendered useless by my forgetting to kill background tasks (such as
Xorg).
---- Next weeks
On vacation December 19th - January 3rd (returning January 4th).
== General ==
* Tidying things up and updating my list of statuses
== String routines ==
* Adding strchr and strlen to eglibc; tests running at the moment.
Dave
[short week, three days]
RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
||cp15-rework || 2012-01-06 || 2012-01-17 || ||
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| ||
(for blueprint definitions: https://wiki.linaro.org/PeterMaydell/QemuKVM)
Historical Milestones:
||add-omap3-networking || 2011-10-13 || 2011-10-13 || 2011-10-13 ||
||a15-systemmode-planning || 2011-10-13 || 2011-10-13 || 2011-09-22 ||
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
== cp15-rework ==
* estimate pushed back a bit because I've ended up doing this in
parallel with the other blueprints. Also exynos4210 review has
taken some time.
== upstream-omap3-cleanup ==
* split up the last handful of patches in the stack which were doing
several things at once
* this blueprint is now complete, meaning that the next stage of omap3
upstreaming will be cleaning up individual subsets of functionality
to send upstream. This is all backburner level priority, though.
== other ==
* reviewed most of Samsung's exynos4210 model
* completed a conflict-heavy rebase of qemu-linaro (the result of
MemoryRegion conversions for omap devices landing upstream)
* LP:903239 : added linux-user support for some missing xattr syscalls
that were causing build problems for apparmor
-- PMM
Hi,
After learning how to control MEM_ALIGN and, therefore, alignment
hints from the vectorizer, I was able to generate 64-bit hints (with
the help of Ramana's patches). I saw a 16% improvement on a benchmark
with stack variables, for which we now force alignment to 64 bits and
create alignment hints, instead of using peeling.
Ira
Hi,
* Finished an across-compilers report for benchmarks over the latest in FSF
and Linaro series. Will start storing results in the
linaro-toolchain-benchmarks bzr repository.
* Looking closer at eembc results, especially regressions between gcc-4.4
and gcc-4.6. Did runs with gcc-linaro-4.4 with -fno-unroll-loop. Will
continue analyze and try to present the result in a good way.
* Reviewed Michael's geomean implementation.
* I will be on Christmas holiday w52 and w01, will be back 9/1.
/Regards
Åsa
Hi there. Could the toolchain team please have a look through the
current GCC blueprints and update them? You can see a list and states
at:
http://apus.seabright.co.nz/helpers/backlog
and for gcc-linaro only at:
http://apus.seabright.co.nz/helpers/backlog/project/gcc-linaro
Please check for any that:
* are on your short-term todo list but aren't against your name
* have been started but are stuck in the backlog or todo
* are finished but not marked as such
* are blocked
* are duplicates or too undefined
* or are obsolete
I'm especially interested in:
* "slp-supported-ops"
* "sms-register-scheduling"
* "better-block-operations"
* "libraries-for-backlog"
* "backport-conditional-execution"
* "improve-peeling"
* "64-bit-sync-pimitives"
* "neon-strided-load-extract"
If you've finished a significant amount of work on one blueprint then
let me know. We can split that work out and push the rest back into
the backlog.
Also, let me know if you're blocked on final benchmarking. We can now
easily benchmark a merge request and see the difference.
-- Michael
Continued work on 64-bit neon operations. The negdi2 seems to be more
difficult than previously thought - vneg won't do it, and there's no way
to encode either "0-reg" or "not(reg)+1", so I'm shelving that idea for
the moment, and moving on to one_compldi2_neon, which ought to be
straight forward.
Did the entire Linaro GCC release process, in the absence of Michael
Hope, from source to announcement. The process didn't go as smoothly as
I'd have liked, but I got through it, mostly. Hopefully Michael won't be
travelling next time ...
Tried to figure out how to do 64-bit shifts using a QImode shift amount.
This promised to eliminate the unnecessary zero-extends, but it doesn't
work because neither iwmmxt or neon registers are permitted to hold
QImode values (presumably changing this would have consequences
elsewhere?). Annoyingly, it's also not possible to put SImode values in
(most) neon registers, so I'm not sure quite how to optimize the values.
More investigation required.
