linaro-toolchain

linaro-toolchain@lists.linaro.org

3 participants
5707 discussions

by Revital1 Eres

Hello, Experiment with aes benchmark from DENbench. Continue my experiments with SMS which includes re-implementing an old patch to insert reg-moves in free slots rather than greedily before the definition as is done in the current implementation. Thanks, Revital

15 years, 1 month

[ACTIVITY] March 13-17

by Ira Rosen

Hi, * submitted store sinking patch to mainline * started testing auto-detection of vector size patch * DENBench - some benchmarks are still unstable, I am looking into stable regressions, adjusting and fixing the cost model for them Next week: Sunday and Monday - holidays Ira

15 years, 1 month

Versatile Express write-up

by Michael Hope

Here's a end-of-cycle write up for Versatile Express support in QEMU: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMUVersatileExpress Most of it is taken from Peter's page: https://wiki.linaro.org/PeterMaydell/QemuVersatileExpress which is the place to go if you want the current state and more detail on the steps involved. While writing this up I had a seamless experience from the first linaro-image-create until seeing the alpha3 greeter come up and wobbling the mouse around. It was awesome. Some ideas for other write-ups at: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs -- Michael

15 years, 2 months

RealView PBX write-up

by Michael Hope

Dave did an investigation earlier in the year into Cortex-A9 and RealView PBX support in QEMU. The write-up is available here: https://wiki.linaro.org/WorkingGroups/ToolChain/Outputs/QEMURealViewPBX Dave and Peter: could you please review it? I've now closed out the blueprint. I'd like to do similar reports on other outputs and will attack vexpress next. -- Michael

15 years, 2 months

Work-item tracking for the "gcc-linaro-tracking" LP project

by Ulrich Weigand

Hi Michael, Andrew, Mounir just pointed out that our non-Ubuntu LP projects (like gcc-linaro, gdb-linaro etc.) are now also included in the LP work-item tracking statistics (http://status.linaro.org/linaro-toolchain-wg.html). This didn't happen in the past due to a Launchpad issue that has now been fixed. This seems to be working out nicely, except for one issue: what about the gcc-linaro-tracking project? I have a couple of bugs that are fixed in Linaro GCC, and are also fixed in mainline GCC, but they still show up as an "in-progress" work-item in the status tracker (there are a whole bunch more of those assigned to Andrew as well). The reason for this is the LP records have an associated gcc-linaro-toolchain project entry, and this is set to "Fix Committed", but not "Fix Released" ... probably because GCC 4.6.0 is not yet released? Now, on the one hand it does make sense to include the -tracking project in the work-item statistics, because they *do* reflect important tasks: namely, to make sure that the changes indeed land in the upstream repository. However, having them all show up as "in progress" until the community makes a new GCC release does not seem very helpful: this is not in our control, and our work is in fact done once the patch is committed upstream. Therefore my suggestion: we should immediately mark -tracking bugs as "Fix Released" (not "Fix Committed"), as soon as the corresponding patch is committed upstream (and thus our work on the problem is completed). Thoughts? Does this make sense? Will this mess up any of the other purposes for which we currently use the -tracking project? Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 2 months

cortex-strings benchmarks

by Michael Hope

Hi Dave. I had a little play with cortex-strings and did some benchmarks on my Tegra 2. Images are attached. I've added two scripts to cortex-strings: scripts/bench-all.sh runs all the routines on all variants and records them scripts/plot.py plots the results from above ploy.py corrects for the benchmark overhead by doing a linear fit to the null 'bounce' results and subtracting this fit. You should be able to a autogen; configure; make; bash scripts/bench-all.sh | tee log.txt; python scripts/plot.py log.txt. I'm sure you have your own favourite tools though. The string routines look good. Lumpy in funny ways though... -- Michael

15 years, 2 months

Fwd: Representing interleaving and lane load/stores at the tree level

by Richard Sandiford

[Sorry, forgot to CC: the list] Hi Ira, Thanks for the feedback. On 6 March 2011 09:20, Ira Rosen <IRAR(a)il.ibm.com> wrote: > > So how about the following functions? (Forgive the pascally syntax.) > > > > __builtin_load_lanes (REF : array N*M of X) > > returns array N of vector M of X > > maps to vldN > > in practice, the result would be used in assignments of the form: > > vectorX = ARRAY_REF <result, X> > > > > __builtin_store_lanes (VECTORS : array N of vector M of X) > > returns array N*M of X > > maps to vstN > > in practice, the argument would be populated by assignments ofthe > form: > > vectorX = ARRAY_REF <result, X> > > > > __builtin_load_lane (REF : array N of X, > > VECTORS : array N of vector M of X, > > LANE : integer) > > returns array N of vector M of X > > maps to vldN_lane > > > > __builtin_store_lane (VECTORS : array N of vector M of X, > > LANE : integer) > > returns array N of X > > maps to vstN_lane > > > > How do you distinguish between "multiple structures" and "single structure > to all lanes"? Sorry, I'm not sure I understand the question. Could you give a couple of examples? The idea is that the arrays above really are array types, regardless of the actual type of the thing we're accessing (which might be a larger array than the bounds above say, or which might be an array of structures or a structure of arrays). That should be OK because arrays alias their elements. Richard

15 years, 2 months

Linaro GDB patch for natty

by Ulrich Weigand

Hi Matthias, in last week's meeting you raised the question what, if any, code from the Linaro GDB repository could be useful for inclusion into the natty GDB package. I've now reviewed the contents of the repository, and my suggestion would be to use everything in Linaro GDB 7.2, except for this commit (which changes the branding to "Linaro GDB"): revno: 32969 committer: Ulrich Weigand <uweigand(a)de.ibm.com> branch nick: 7.2 timestamp: Wed 2010-09-22 19:18:38 +0200 message: 2010-09-22 Ulrich Weigand <uweigand(a)de.ibm.com> * src-release: Support gdb-linaro packages. gdb/ * version.in: Set to Linaro GDB version number. * configure.ac (PKGVERSION, BUGURL): Refer to Linaro. * configure: Regenerate. gdb/gdbserver/ * configure.ac (PKGVERSION, BUGURL): Refer to Linaro. * configure: Regenerate. gdb/doc/ * configure.ac (PKGVERSION, BUGURL): Refer to Linaro. * configure: Regenerate. (Instead, the branding ought to be set as appropriate for the Ubuntu package. Maybe with an additional reference to Linaro, just as with GCC?) I've created a snapshot of the Linaro GDB 7.2 branch using the command bzr diff --prefix a/:b/ -r32965.. and then manually removed changes to src-release gdb/version.in gdb/configure.ac gdb/configure gdb/gdbserver/configure.ac gdb/gdbserver/configure gdb/doc/configure.ac gdb/doc/configure I've left in the new file ChangeLog.linaro for documentation purposes, but if you prefer this could of course be removed as well. The resulting patch is appended here. (Note that I'd recommend to continue updating the patch from Linaro GDB as further changes make it in.) (See attached file: linaro-gdb.patch) I've then added the patch to the natty GDB package. Since it touches a completely distinct set of files compared to the existing list of patches in the package, it can be added to the series file at any arbitrary point. I've built the resulting compiler on i386, arm, and ppc64, and it strictly improved the test results on all three platforms: i386 without patch: # of expected passes 16161 # of unexpected failures 114 # of expected failures 72 # of untested testcases 9 # of unresolved testcases 1 # of unsupported tests 69 i386 with patch: # of expected passes 16331 # of unexpected failures 24 # of expected failures 72 # of untested testcases 9 # of unresolved testcases 1 # of unsupported tests 69 Fixed test case failures are from: gdb.base/break-interp.exp gdb.base/foll-fork.exp gdb.base/printcmds.exp (These are just test suite cleanups, no actual code changes.) ppc without patch: # of expected passes 15350 # of unexpected failures 74 # of expected failures 53 # of untested testcases 15 # of unresolved testcases 1 # of unsupported tests 63 ppc with patch: # of expected passes 15350 # of unexpected failures 55 # of expected failures 53 # of untested testcases 15 # of unresolved testcases 1 # of unsupported tests 63 Fixed test case failures are from: gdb.base/printcmds.exp gdb.threads/local-watch-wrong-thread.exp gdb.threads/watchthreads.exp (These are just test suite cleanups, no actual code changes.) arm without patch: # of expected passes 15343 # of unexpected failures 270 # of unexpected successes 1 # of expected failures 65 # of untested testcases 11 # of unresolved testcases 2 # of unsupported tests 70 arm with patch: # of expected passes 15686 # of unexpected failures 46 # of unexpected successes 3 # of expected failures 63 # of untested testcases 11 # of unresolved testcases 1 # of unsupported tests 69 Fixed test case failures are from: gdb.base/break-interp.exp gdb.base/corefile.exp gdb.base/foll-fork.exp gdb.base/gcore.exp gdb.base/gdb1555.exp gdb.base/pr11022.exp gdb.base/printcmds.exp gdb.base/recurse.exp gdb.base/relativedebug.exp gdb.base/step-test.exp gdb.base/watch-cond.exp gdb.base/watch-read.exp gdb.base/watch_thread_num.exp gdb.base/watch-vfork.exp gdb.gdb/selftest.exp gdb.mi/gdb792.exp gdb.mi/mi2-syn-frame.exp gdb.mi/mi2-var-display.exp gdb.mi/mi2-watch.exp gdb.mi/mi-syn-frame.exp gdb.mi/mi-var-display.exp gdb.mi/mi-watch.exp gdb.pie/corefile.exp gdb.server/ext-attach.exp gdb.threads/attachstop-mt.exp gdb.threads/attach-stopped.exp gdb.threads/linux-dp.exp gdb.threads/local-watch-wrong-thread.exp gdb.threads/pthread_cond_wait.exp (This represents much of the bug fix work that went into Linaro GDB.) Let me know if there's any further information you need, or anything else I can do to help get the Linaro changes into natty GDB. Mit freundlichen Gruessen / Best Regards Ulrich Weigand -- Dr. Ulrich Weigand | Phone: +49-7031/16-3727 STSM, GNU compiler and toolchain for Linux on System z and Cell/B.E. IBM Deutschland Research & Development GmbH Vorsitzender des Aufsichtsrats: Martin Jetter | Geschäftsführung: Dirk Wittkopp Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht Stuttgart, HRB 243294

15 years, 2 months

[ACTIVITY] 7th - 13th March

by Andrew Stubbs

Merged fixes for several bug into Linaro GCC 4.5. Both from Linaro (Richard, Matthias and Ramana), and from CS (the shrink wrap problems). Continued working on benchmarking the patches I've merged to 4.6. Spent quite some time trying to figure out why EEMBC and the Spec2K weren't working properly. I've got this sorted now. Confirmed that the patch to discourage NEON use for integer operations is still profitable on Cortex-A8. Posted the patch upstream. Merged upstream GCC 4.6 into Linaro GCC 4.6. Booked travel to Budapest for Linaro @ UDS. Followed up on Ramana's questions about the RVCT interoperability patch. Paul Brook helped explain what it was about, and pointed me at the proper section in the proper ARM manual. Continued forward porting patches to 4.6. Mostly I need to convince myself that they still do something useful. I have posted one new patch to upstream - the "Discourage A8 NEON" patch. * Future Absence Away Wednesday 16th to Friday 18th. Away Monday 28th to Friday 1st April. ---- Upstream patched requiring review: * Thumb2 constants: http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00652.html * ARM EABI half-precision functions http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00874.html * ARM Thumb2 Spill Likely tweak http://gcc.gnu.org/ml/gcc-patches/2011-02/msg00880.html * NEON scheduling patch http://gcc.gnu.org/ml/gcc-patches/2011-02/msg01431.html * RVCT Interoperability patch http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00059.html * Discourage NEON on A8 http://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg00576.html

15 years, 2 months

[ACTIVITY] Mar.07 -- Mar.13

by Chung-Lin Tang

== Last week == * Working on Coremark ARMv6 regressions. Identified a major cause being RTL ifcvt failing on one of the crc routines, due to combine pass failing to optimize a particular sequence, causing the if-conversion estimates to give up on conditional executing (too many insns). The combine pass failed on ARMv6 and above, due to the existence of true zero_extend insns. On ARMv5, the use of two shifts actually allowed combine to phase reduce the shifts one by one, thus producing better code. On ARMv6, combine produced a (xor (and ...) <mask>) which did not match any insn. Analyzed and sent a patch upstream which should work on such XOR cases. Patch is due for upstream commit for 4.7-stage1. (http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00609.html) * Another situation of un-optimized uxth insns still exists; trying to solve this by another combine patch I am currently testing, will send upstream later. == This week == * verify the improvements the above patches should have on Coremark for ARMv6/v7. * Work on sending them to Linaro and SG++ branches. * Other bug issues.

15 years, 2 months

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

linaro-toolchain