On Mon, Nov 21, 2011 at 11:50 PM, Andrew Stubbs
wrote:
> Continued looking at constant reuse optimizations, as a background task.
> I've fiddled with the costs a bit more to remove false positives.
>
> Continued benchmarking different generic tuning ideas. With each test run
> taking most of a day
RAG :
RED : None
AMBER: Worried about trunk failures with test runs. Number of
testsuite failures after the atomics merge has increased - more below.
.
TaskPlanned Estimated Actual
Historical
~~~
Connect 2011.q4
preparation 28/
== GDB ==
* Ongoing work on support for cross-platform core file generation.
== GCC ==
* Investigated Launchpad bugs:
#889984 binaries: should step across helper functions
#889985 binaries: can't step out of helper functions
#890764 4.6-11.11 seems to misdetect some files as system h
Defining a macro seems to eat up about half a megabyte of memory,
due to the excessively large size of the macro arguments hash table
(large enough for 65537 entries by default).
As a result, gas memory consumption becomes rather huge when a
modestly large number (hundreds) of macros are defined.
I discovered some excessive memory usage in gas recently when
defining macros. It turns out that this is a weird implementation
feature rather than a bug.
This patch has a possible fix for the issue, but I'd be interested
in people's views before I go so far as cleaning it up and
discussing it up
Continued looking at constant reuse optimizations, as a background task.
I've fiddled with the costs a bit more to remove false positives.
Continued benchmarking different generic tuning ideas. With each test
run taking most of a day this is slow going.
Took Michael's rootfs that is used for
Sent the patch which implements register pressure estimation in SMS to
the gcc mailing list as RFC.
I looked at some of the regressions in libav and intend to continue
with that this week.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.o
== Last week ==
* Caught up on lots of email.
* Looked into the SMS regression that Revital found. Turned out to be
caused by the ARM backend not modelling the VMLA fast accumulator path.
Need to know how the path actually works before modelling it
(the docs aren't clear).
* Continued to
