Hi,
I was on vacation on Sunday and starting from Tuesday stayed home with
a sick child, so I only had a couple of days to work.
* vectorization of Viterbi:
- continued implementing conditional store sinking in cselim pass
- made if-conversion to work on loads of structure fields if other
field from the same structure is accessed unconditionally
* fixed GCC PR 47001.
Ira
Continued looking at SPEC 2006.
The two ICEs I mentioned last week are gone on the Natty version of the
compiler, however the 4 programs that run and give the wrong
results still happen with the Natty version and the latest version from bzr.
The 4 failures are:
h264ref - still fails on bzr 99447 with -O2 or -O0
sphinx3 - still fails on bzr 99447 with -O2 or -O0
gromacs - still fails on bzr 99447 with -O2 but works with -O1; I've
followed this through and detailed it in bug 693502; it looks to me like
a post-increment gone wrong (it's split so it's not
actually a post increment and the original rather than post inc'd value gets
used)
zeusmp - this fails to load the binary; it's got a >1GB bss section.
Interestingly it gets further on my beagle with less memory but a bit of
swap,
even though I think it's not really using all of the BSS
in the config I'm using.
I'm hoping to leave a 'ref' run going over the new year.
The canis1 Orion board I was also running Spec on last weekend died during
the run and hasn't come back.
perf
We now have silverberry using the -proposed kernel which has the fixed
PERF_EVENT config, and perf seems to work fine.
libffi
I've started building the page
https://wiki.linaro.org/WorkingGroups/ToolChain/FFIusers listing things
that use FFI; (generated by a bit of apt wrangling).
There are basically 3 sets:
a) Apps that just use ffi for something specific
b) Languages that then let the users of those languages have varying
degrees of freedom in themselves
c) Haskell - While some of the packages are actually probably ffi
users, I think a lot of these are false dependencies; almost every haskell
user seems
to gain a dependency on libffi directly.
I'm back on the 4th January.
Dave
Hi,
I continued looking into EEMBC benchmarks:
- telecom fft is not vectorized because unknown number of iterations.
It has both non-constant step and its loop bound may overflow. I
think, the solution here could be loop versioning, but since
versioning increases code size, this kind of optimization can be less
beneficial.
- telecom viterbi (vectorization potential gain is 4x) requires
conditional store sinking and load hoisting to enable if-conversion. I
worked on implementation of store sinking this week.
Ira
Ulrich Weigand/Germany/IBM wrote on 12/20/2010 06:01:21 PM:
> Mark Mitchell <mark(a)codesourcery.com> wrote:
> > On 12/20/2010 8:35 AM, Ulrich Weigand wrote:
> > > Now, I guess there's two ways forward: either the outcome of the
ongoing
> > > discussions on gcc-patches is that it is in fact not a good idea to
> > > generate such sets, and the EE pass is subsequently rewritten to
avoid
> > > them; or else, if those instructions are considered valid, I'll have
to
> > > extend the SPU move expander to handle them. Thoughts?
> >
> > I haven't participated in the upstream discussion -- I'm way behind on
> > that list :-( :-( -- but I think such sets should be considered valid.
>
> OK, I'll have a look at fixing the SPU back-end then.
I've now fixed this problem in the back-end upstream:
http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01694.html
I've also created a back-port to Linaro GCC 4.5 and proposed the
branch for merge; you can find the details at:
https://bugs.launchpad.net/gcc-linaro/4.5/+bug/693425
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
== Last Week ==
* Continued working on ARM unwinding in libunwind. Produced a draft
write-up of my progress in the event that I don't finish this work
before being swapped out of Linaro.
* (Re-)submitted patches to fix ltrace test suite. Hopefully, these will
be the last changes before the new release.
== This Week ==
* Continue working on libunwind.
--
Zach Welch
CodeSourcery
zwelch(a)codesourcery.com
(650) 331-3385 x743
Hi,
We would like to build Android with the Linaro tool chain. Do any of you
know what kind of work will be needed to adapt Linaro gcc to Android?
Regards,
Patrik
== GCC related ==
* CS Issue #10201 / PR46883, unrecognizable insn ICE when compiling
Samba. Fixed this by changing the predicates of two split patterns.
Patch reviewed in CS internally and upstream, committed upstream, will
backport to SG++ and Linaro soon.
* LP:641397/PR46888: bitfield insert optimization. Andrew Pinski found a
testcase that escapes the CSE patch gets handled by combine, and also
found another bug with REG_EQUIV notes. Only looked at this minimally
last week, will really work on this later.
* LP:687406/PR46865, -save-temps creating different code. Backported and
bzr-pushed the upstream fix by Jakub Jelinek.
* PR45416, ARM code regression. Mostly can generate what I wanted by
now, under ARM and x86, although patch is still not in a submittable state.
* VFP index patch. Uncommitted GCC patch of mine from last year; added
Thumb-2 bits and corrected some things in the testcase. Committed upstream.
== This week ==
* Really get January travel stuff nailed.
* Upstream patch review is probably going to start getting
slow/suspended this week. Will probably do some study stuff on larger
projects.
* Continue to look at GCC issues.
== Linaro GDB ==
* LP:615972 Different output of 'info register' w/ and wo/ corefile.
Understands gcore impl in gdb. Two patches are reviewed in upstreams.
One is approved by Dan, and the other is still be reviewed.
Evaluate the two approaches for NEON registers in corefile. Resume the
discussion on kernel support for dumping NEON registers. Need a
decision with kernel side, but no progress on it.
* LP:685494 Revise patch per Pedro's suggestion. Waiting for someone
to approve it.
* LP:685702 Get it approved for FSF GDB 7.2 branch. Committed to both
FSF 7.2 branch and Linaro tree.
* LP:616003 gdb.mi/mi-var-display.exp failure
GDB always assumes $fp is r11, even code is in thumb mode. Current GDB
infrastructure can't handle mapping the same alias to two different
registers. Proposed a new gdbarch took for this in upstreams, in order
to increase the flexibility of GDB. No reply yet.
* LP:616001 gdb.mi/mi-var-cmd.exp failure
Ulrich pointed out it is caused by stack randomization. Confirmed this
by setting "kernel.randomize_va_space" to zero. Figure out why this
case passes on x86, because it is more restricted to turn on stack
randomization on x86.
* LP:615980 Support displaced stepping on Thumb
Understands displaced stepping in GDB/ARM. Find a bug when GDB tries to
execute ARM instruction in copy area, which is in Thumb mode (copy area
starts from "_start + 4", and it is compiled in Thumb mode in Ubuntu).
The fix is an one-line patch, which doesn't update status register when
writing PC in displaced stepping.
Write a test case for arm displaced stepping. Write code in ARM asm
directly for the first time, which is very helpful to remember ARM asm
instructions.
Read ARM ARM and decode 16-bit thumb instructions in GDB for displaced
stepping. It doesn't work so far because breakpoint instruction after
instructions in copy area is still hard-coded to ARM breakpoint insn.
== Misc ==
* Linaro GCC optimization meeting.
== This Week ==
* LP:615980 Support displaced stepping on Thumb
Send my fix and test case to upstreams for review.
Make displaced stepping work on 16-bit instruction.
* Ping other GDB patches.
--
Yao (齐尧)
Mark Mitchell wrote:
> > If Profile Guiding could spot that a particular callsite to say strlen()
> > was often associated with strings
> > of at least 'n' characters we could call a different implementation.
>
> I don't believe this is possible current profile-guided optimization,
> but certainly it could be done.
It looks to me like a case of value profiling, see tree-profile.c, for
the various "stringops" optimizations. Unless I misunderstand David's
idea here or missing something else, it seems that this kind of
optimization should fit in the existing infrastructure without too much
effort.
Ciao!
Steven
Does anyone have any experience of what can be profiled in the profiled
guided optimisations?
One of the problems with some of the string routines is that you can write
pretty neat fast routines that
work well for long strings - but most of the calls actually pass short
strings and the overhead of the
fast routine means that for most cases you are slower than you would have
been with a simple routine.
If Profile Guiding could spot that a particular callsite to say strlen() was
often associated with strings
of at least 'n' characters we could call a different implementation.
Dave
