Hi,
Does anyone have anything they'd like to bring up in tomorrow's
performance call. ? I don't have any topics other than following on
action items from last time's call - which was comparing movw/ movt
with constant pools .
https://wiki.linaro.org/WorkingGroups/ToolChain/Meetings/2012-01-10
Please add to it as you deem fit.
cheers
Ramana
* Linaro
Continued work on getting GCC to build on LAVA. I've ironed out a few
more bugs from my test scripts, but it's slow going because a test runs
takes a long time to run, and there are very few useful error messages
when something goes wrong.
Wrote, posted, and committed a patch to fix the "120" testsuite bug I
encountered last month. Basically the GCC testsuite's "headmerge-1"
testcase would have failed from now until September because a sloppy
regex happening to match "120" in the toolchain version string's
snapshot date. I've also backported it to upstream 4.6 and posted a
merge request for Linaro 4.6.
Continued running benchmarks for the generic tuning project.
Continued looking at optimizing 64-bit shifts. No real progress this
week though.
* Other
Monday: Public holiday.
Tuesday: Vacation.
Caught up on a mountain of email.
Summary:
* Read armV7-A/R reference manual and analyze bugs.
Details:
* Read armV7-A/R reference manual and share the instruction set part
with local team.
* Analyze bugs: LP: #889985 "binaries: can't step out of helper
functions" and LP: #889984 "binaries: should step across helper
functions"
Plan:
* Ramp-up on gcc.
Planed leave:
* Jan 21 - 29: Chinese new year holiday.
Best regards!
-Zhenqiang
Hi there. I want each administrative task inside our group to have an
owner and a fill-in. I've started a list at:
https://wiki.linaro.org/WorkingGroups/ToolChain/Jobs
I took the chance to hand off some of my jobs as well so you might see
your name somewhere new (but hopefully not surprising).
I'll discuss this at tonight's meeting and in the 1-on-1s. Reply away
if you'd like more detail or have a task to add.
-- Michael
[short week, three days]
RAG:
Red:
Amber:
Green:
Current Milestones:
|| || Planned || Estimate || Actual ||
||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:
||a15-usermode-support || 2011-11-10 || 2011-11-10 || 2011-10-27 ||
||upstream-omap3-cleanup || 2011-11-10 || 2011-12-15 || 2011-12-12 ||
== other ==
* catchup on email, etc
* patch review: patches for Calxeda's Highbank SoC model
* put together pull requests for target-arm and arm-devs patchqueues
* rebased qemu-linaro, added patches for things we want to fix in 2011.01,
rolled a tarball, tested it and sent to Michael H for testing
Hi Ramana. You were right about being able to do operations on
intrinsic types. Instead of doing the admittedly made up:
int16x4_t foo2(int16x4_t a, int16x4_t b)
{
int16x4_t ca = vdup_n_s16(0.2126*256);
int16x4_t cb = vdup_n_s16(0.7152*256);
return vadd_s16(vmul_s16(ca, a), vmul_s16(cb, b));
}
you can do:
int16x4_t foo3(int16x4_t a, int16x4_t b)
{
int16x4_t ca = vdup_n_s16(0.2126*256);
int16x4_t cb = vdup_n_s16(0.7152*256);
return ca*a + cb*b;
}
which is more readable and, as an added bonus, generates the
multiply-and-accumulate that I missed when using intrinsics. Nice.
-- Michael
== GDB ==
* Ongoing discussion on remote support for "info proc" and
core file generation.
* Fixed various GDB 7.4 regressions on multiple platforms.
== GCC ==
* Patch review week.
* Started looking into current status of performance patches.
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
Hi,
* Android
* migrated my linaro android build environment
* did a small change to the debuggerd patch (thanks Sylvain)
* OpenEmbedded
* the linaro binary toolchain uses multiarch paths while OE doesn't
-> setup a workaround to make it look like a classic one
* however, I think what I really want is to build the libc instead
of using the one provided by the binary external toolchain
* The core-image-minimal still doesn't boot properly because 'init'
doesn't come properly
Regards
Ken
The remaining change for neon-strided-load-extract is to allow fwprop.c
to propagate:
(set (reg X) (subreg (reg Y) N))
even if no further simplifications are possible. I posted the original
patch for comments here:
http://article.gmane.org/gmane.comp.gcc.patches/246180/
and fixed the problem that H.J. spotted. I wasn't entirely happy with
the benchmark results though, so it never became an RFA.
Richard
gcc/
* fwprop.c (propagate_rtx): Also set PR_CAN_APPEAR for subregs.
Index: gcc/fwprop.c
===================================================================
--- gcc/fwprop.c 2011-09-15 14:36:23.206143787 +0100
+++ gcc/fwprop.c 2011-09-15 14:36:40.995131564 +0100
@@ -664,7 +664,12 @@ propagate_rtx (rtx x, enum machine_mode
return NULL_RTX;
flags = 0;
- if (REG_P (new_rtx) || CONSTANT_P (new_rtx))
+ if (REG_P (new_rtx)
+ || CONSTANT_P (new_rtx)
+ || (GET_CODE (new_rtx) == SUBREG
+ && REG_P (SUBREG_REG (new_rtx))
+ && (GET_MODE_SIZE (mode)
+ <= GET_MODE_SIZE (GET_MODE (SUBREG_REG (new_rtx))))))
flags |= PR_CAN_APPEAR;
if (!for_each_rtx (&new_rtx, varying_mem_p, NULL))
flags |= PR_HANDLE_MEM;