Hi,
* catching up with emails
* rebased against current OE-core
* OE is planning a release in april (following the yocto schedule)
* noticed the libc of our binary toolchain is lacking i18n
* caused a packaging issue for meta-linaro but easy to workaround
* contents of the i18n folder are only used at runtime (not relevant
for compiliation time)
* updates in order to support for the 2012.03-20120326 binary toolchain
* locations of sibgcc_s.so and libstdc++.so are different
* added support for linaro gcc 2012.04
* looked at the meta-linaro patches made by Khem
Regards,
Ken
The EEMBC supplied build system has a couple of bugs with library
order (putting -lrt at the start of the command line instead of the
end) and the harness library (depending on THOBJS but linking against
THLIB). I've fixed these and pushed to our private branch.
Ulrich, I've spawned builds of your vld1.64 branch and its ancestor.
Once those are done I'll spawn a benchmark run against them.
-- Michael
Summary:
* Code size benchmark analysis.
* Linaro binary toolchain 2012.04 release.
Details:
1. Tuning the heuristic to assign register for copies.
* Take the CONFLICT_HARD_REGS and HARD_REG_COSTS of copies into
account when conflict_costs is NULL in
update_conflict_hard_regno_costs, which handles the following case:
a = ...
...
b = a // a can be assigned with r3 or r5 which have the same min_cost.
... // b is conflicted with r3 or the cost of r3 is very high
= b
In this case, if a is assigned with r3, b can not be assigned with
r3, so the copy "b = a" can not be optimized. When taking the
CONFLICT_HARD_REGS or HARD_REG_COSTS of b into account, we can assign
a with r5.
2. Linaro binary toolchain 2012.04 release.
* Update gdb/TOOLCHAIN_PKGVERSION/README to 2012.04.
* Test workaround localization patch to fix lp:918926.
* Local build and tests show the toolchain can find the
corresponding .mo file.
* But if the host system does not have the corresponding font
packages, it will show some mess characters.
* gdb does not have gdb.mo.
3. Investigate code size regressions in 4.7.
* Loop invariant hoisting might increase register pressure, which
leads to much more spilling.
Plans:
* Finalize Linaro binary toolchain 2012.04 release
* Investigate other code size regressions in 4.7.
Planed leaves:
* Labor Day’s holiday: April 30 and May 1.
Best regards!
-Zhenqiang
Hi,
I have been using CodeSourcery tool-chains since forever, and I
decided to try Linaro's tool-chain. So far I haven't had any issues,
except one:
libgcc_s.so.1 is located in arm-linux-gnueabi/lib, which is not
available from arm-linux-gnueabi/libc. The CodeSourcer tool-chain has
all those files inside the 'libc' directory, which is useful for
Scratchbox2, because you need to specify a "target root" which is
basically the libc directory which acts in a similar fashion to /.
I've managed to create a rule to workaround this issue, but I wonder
why are those files in that location, why not in 'libc/lib'?
Cheers.
--
Felipe Contreras
=== Progress ===
* Worked on the VFP addressing modes patch upstream. Handled most
comments. Final version has finished testing and looks almost ready to
commit.
* Investigated an issue with min type transformations for loop
terminating conditions. Wrote up a small patch which appears to do the
right thing - passed a bootstrap on x86 but that probably means it
never got triggered :( .
The particular case of interest was not vectorizing :
#define min(x,y) ((x) <= (y) ? (x) : (y))
int a[256] __attribute__((aligned (16)));
int b[256] __attribute__((aligned (16)));
int c[256] __attribute__((aligned (16)));
void foo (int x, int y)
{
int i;
for (i = 0;
i < x && i < y;
// i < min (x, y);
i++)
a[i] = b[i] * c[i];
}
but vectorizing the commented region. I've tentatively worked out a
fix in tree-loop-im.c which looks like a bit of a grotesque hack ....
* Attended LLVM devcon in Week 15. Useful and interesting and conference.
== Plans ==
* Pursue backporting gnu_unique_object upstream.
* Look at some of the existing blueprints and start discussions around
prioritizing this.
* Investigate some of the SEGVs with h-c partitioning.
* Finish off the VFP addressing modes patch.
Absences.
* 03 May 2012 - 08 May 2012.
* Linaro Connect Q2.12 - May 28 - June 1 -
== GCC ==
* Checked in backport patch to fix LP #972648
into Linaro GCC 4.6.
* Checked in fix for incorrect vld alignment hints to
FSF mainline and 4.7 branch.
* Investigated options to fix stack re-alignment.
* Ongoing investigation of LP #959242: design problem in vectorizer
pattern detection logic causes ICE in certain cases where an
original sequence is recognized as part of *two* potential patterns
simultaneously.
* Ongoing work on improving end-of-loop value computation.
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
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-04-10 || ||
Historical Milestones:
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 ||
== cp15-rework ==
* sent out v1 patchseries for cp15 cleanup to the mailing list, finally
* handled review comments on drop-cpu-reset-model-id patchseries
== kvm-boot-wrapper ==
* imported libfdt device tree library and Dave Martin's code from
the big.LITTLE boot-wrapper, to add support to the KVM boot wrapper
for handling device tree blobs. Patch series sent, will probably
commit next week unless there are review issues
* that will more or less wrap this blueprint up
== other ==
* usual upstream patch review; QEMU 1.1 soft feature freeze was start
of this week, hardfreeze will be beginning of May, people (including
me :-)) are trying to squeeze things in under the wire...
-- PMM
* Linaro GCC
Investigated the latest test failure for the neon-extend patch. The test
for GCC Bugzilla 43137 is failing again. It turns out to be because my
switching sign_extend to use a DImode output, rather than two SImode
subreg outputs has exposed a bug in the lower-subreg pass. I've spent
most of the week trying to figure what can be done about this and
discussing the problem with Richard Sandiford upstream.
Richard Earnshaw approved my neon-negate patch. That patch depends on
the neon-immediates patch which is not approved yet, so I'll have to
wait to commit it.
Continued looking at NEON-v-core register allocation. Not much progress
this week though.
* Other
Created a patch to make the GCC RTL dumps easier to diff. Posted it
upstream and discussed it on the list.
Vacation on Friday.
* Next week
Vacation Monday and Tuesday
Hello,
I've been following up on the discussion we had on Monday regarding stack
alignment, and noticed that I had mis-remembered the current state of
affairs. Ramana asked me on Tuesday to provide a write-up of the actual
status, so here we go ...
To summarize the background of the problem: on ARM, the incoming stack
pointer is only guaranteed to be aligned to an 8 byte boundary. This means
that objects on the stack (local variables, spill slots, temporaries etc.)
cannot easily be aligned to more than 8 bytes. This can potentially cause
problems in two situations:
1) The object's default alignment (according to its type) is larger than 8
bytes
2) The object has a forced non-default alignment that is larger than 8
bytes
The first situation should in theory never appear, since according to the
ARM ABI all types have a default alignment of at most 8 bytes. However,
due to the current mix-up in GCC, vector types actually are considered to
have a 16-byte alignment requirement in GCC.
The second situation can only appear with local variables that are declared
using attribute ((aligned)).
We had discussed on Monday that we need to fix the second situation, since
this can always occur and is supported on other platforms. By doing so,
we would then automatically fix the first situation as well.
However, this reasoning turns out to be incorrect. There are currently in
GCC *two* completely separate mechanisms that can be used to align objects
on the stack to larger than the ABI guaranteed stack pointer alignment:
A) Re-alignment of the full stack frame. This is what is used by the Intel
back-end (and only the Intel back-end). At function entry, generated code
will align the stack pointer itself to whatever is necessary to fulfil
alignment requirements of all objects on the stack. This may necessitate
follow-on changes: the frame pointer, if there is one, will likewise need
to be aligned at runtime. Also, since incoming stack arguments are now no
longer at a fixed offset relative to the stack pointer *or* frame pointer
in some cases, we might need an extra register as argument pointer. This
method allows extra alignment for *any* object on the stack, but needs
significant back-end support in order to be enabled on any non-Intel
architecture.
B) Dynamic allocation of selected stack variables. This is implemented by
common code with no involvement of the back-end. In effect, the code in
cfgexpand.c:expand_stack_vars that decides on how to allocate local
variables on the stack will remove all variables that require extra
alignment and place them into an extra structure. Generated prologue code
will then in effect dynamically allocate and align that structure on the
stack, and just store a pointer to it as "variable" into the normal stack
frame. All other areas of the frame are unaffected. Since this method
just simulates code the programmer could have written themselves using
alloca, it does not require *any* back-end support and is enabled by
default everywhere. However, it only works for regular local variables,
and not for any other objects on the stack.
Objects on the stack *except* local variables always use default alignment.
Since on most platforms, except Intel and *currently* ARM, the ABI stack
pointer alignment is sufficient to implement default alignments, method B)
as above is able to fulfil all stack alignments. Intel uses method A), so
they're also OK. In effect, it's only ARM due to the vector type
alignment problem that runs into the situation that neither method works.
Under those circumstances, given that:
- we want to fix vector type alignment in order to become ABI compliant
- once we've fixed this, we're in the same situation as other platforms and
method B) already fixes stack alignment problems
- implementing method A) is therefore both quite involved *and* actually
superfluous
I'd now rather recommend that we *don't* try to implement method A) (full
stack-frame re-alignment) on ARM.
Comments?
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
Vorsitzende des Aufsichtsrats: Martina Koederitz | Geschäftsführung: Dirk
Wittkopp
Sitz der Gesellschaft: Böblingen | Registergericht: Amtsgericht
Stuttgart, HRB 243294
Hi,
GDB for Android:
* Continued conversation about .note.ABI-tag.
* Committed upsream the second of three patches for building
gdbserver on Android.
* Continued working on a crtbrand.c for bionic.
2012.04 release:
* Tested the gdb-linaro/7.4 branch on armv5tel, x86 and x86_64, both
natively and remotely. Compared results against the 2012.02 release.
* Ran the release process, made the release.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
Hi,
GDB for Android:
* Investigated .note.ABI-tag generation in glibc and FreeBSD.
Wrote crtbrand.c for bionic based on FreeBSD's crtbrand.c.
Tried to integrate it with bionic's build system.
* Contacted Google engineers about adding .note.ABI-tag to Android
binaries.
2012.04 release:
* Started working on the release. Applied the latest patches from
the FSF 7.4 branch to gdb-linaro/7.4 and also my patches to compile
gdbserver with the Android toolchain.
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
* Linaro GCC
Spun release tarballs for Linaro GCC 4.6 and 4.7. Pushed them to
Michael's servers and launched the testing.
Continued trying to get the 64-bit NEON stuff to work. The negdi2 patch
needed some reworking following upstream review, and the extend patch
has mysteriously reintroduced a performance regression when the
operation is done in core-registers, which needs to be solved, but the
other patches seem ok at the moment, although the shift stuff is blocked
on benchmarking.
I've begun looking at how my changes affect spec2000, and whether the
register allocation could be done better. Unfortunately, given that the
test systems are currently giving spec results with a low level of
consistency (and therefore confidence), this has mostly been by visual
inspection, so far.
* Other
Public Holiday on Monday.
I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to.
I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something?
-Allen
nvpublic
Current Milestones:
|| || Planned || Estimate || Actual ||
||cp15-rework || 2012-01-06 || 2012-04-10 || ||
Historical Milestones:
||initial-a15-system-model || 2012-01-27 || 2012-01-27 || 2012-01-17 ||
||qemu-kvm-getting-started || 2012-03-04?|| 2012-03-04?|| 2012-02-01 ||
== cp15-rework ==
* completed last of the register conversions, started on the final
check-through and polish before it goes out to the mailing list
* implemented changes following review of the clean-up-reset patchset
== other ==
* qemu-linaro 2012.04 final testing (confirming an audio issue on
the vexpress model LP:977610 wasn't a regresion) and release
* patch review: pl330 dma controller model
* patch review: samsung's sd card model overhaul
* minor patch: fix compile failure on bsd
* minor patch: fix failure to reset timer on a9 mptimer reset
* minor patch: diagnose attempts to use python3 at configure time
* sent arm-devs.next pullreq
* put together a bug report in the form of a youtube video (!) as
requested by the gmail folks
-- PMM
== GCC ==
* Committed fix for LP #968766 (PR tree-optimization/52880)
to FSF mainline and Linaro GCC 4.6 and 4.7.
* Created merge reqest to fix LP #972648 for Linaro GCC 4.6
by backporting mainline patch; pending approval.
* Updated patch to use vld1.64/vst1.64 instead of vldm/vstm
for vector moves. Testing detected problems in GCC core
memory alignment logic (GCC assumes vector types are
naturally aligned, which contradicts ARM ABI and ARM
back-end assumptions). Started discussion on possible
fixes.
* Updated and retested patch to use vld1/vst1 to implement
vec_set/vec_extract for cases where the scalar operand
resides in memory.
* Ongoing work on fixing LP #959242.
* Ongoing work on improving end-of-loop value computation.
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
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro GDB 7.4 2012.04.
Linaro GDB 7.4 2012.04 is the second release in the 7.4 series. Based
off
the latest GDB 7.4, it includes a number of ARM-focused bug fixes and
enhancements.
Interesting changes include:
* gdbserver can now be compiled with Android's toolchain.
* Additional fixes from the GDB 7.4 branch, one of them being
that it doesn't require makeinfo to build anymore.
The source tarball is available at:
https://launchpad.net/gdb-linaro/+milestone/7.4-2012.04
More information on Linaro GDB is available at:
https://launchpad.net/gdb-linaro
--
[]'s
Thiago Jung Bauermann
Linaro Toolchain Working Group
The Linaro Toolchain Working Group is pleased to announce the release of
Linaro QEMU 2012.04.
Linaro QEMU 2012.04 is the latest monthly release of qemu-linaro. Based
off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes
and enhancements.
New in this month's release:
- ppoll syscall now supported in ARM linux-user mode
- the SETEND instruction in the Thumb encoding now UNDEFs to
match behaviour for the ARM encoding
- the OMAP36xx UART FIFO status registers are now implemented
(thanks to Jan Vesely)
Known issues:
- Graphics do not work for OMAP3 based models (beagle, overo)
with 11.10 Linaro images.
- Audio may not work on Versatile Express models with the latest
Linaro kernel/hardware packs (LP:977610).
The source tarball is available at:
https://launchpad.net/qemu-linaro/+milestone/2012.03
More information on Linaro QEMU is available at:
https://launchpad.net/qemu-linaro
The Linaro Toolchain Working Group is pleased to announce the 2012.04
release of both Linaro GCC 4.7 and Linaro GCC 4.6.
Linaro GCC 4.7 2012.04 is the first release in the 4.7 series. Based
off the latest GCC 4.7.0+svn186061 release, it includes performance
improvements especially around 64 bit operations.
Interesting changes include:
* Our first 4.7 based release
* Updates to GCC 4.7.0+svn186061
* Better use of 16 bit Thumb-2 instructions for smaller code size
* Implements 64 bit ones complement in NEON
* Adds support for the ARMv6 saturation instructions
* Backports the NEON lexer improvements for faster compilation
* Backports the 64 bit multiply, divide, and mod improvements
Fixes:
* LP: #960283 slp pass assert when compiler configure with --enable-checking
Linaro GCC 4.6 2012.04 is the fourteenth release in the 4.6 series.
Based off the latest GCC 4.6.3+svn186060 release, this is the first
release after entering maintenance.
Interesting changes include:
* Updates to 4.6.3+svn186060
Fixes:
* LP: #960283 slp pass assert when compiler configure with --enable-checking
The source tarballs are available from:
https://launchpad.net/gcc-linaro/+milestone/4.7-2012.04https://launchpad.net/gcc-linaro/+milestone/4.6-2012.04
Downloads are available from the Linaro GCC page on Launchpad:
https://launchpad.net/gcc-linaro
More information on the features and issues are available from the
release page:
https://launchpad.net/gcc-linaro/4.7/4.7-2012.04
Mailing list: http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Bugs: https://bugs.launchpad.net/gcc-linaro/
Questions? https://ask.linaro.org/
Interested in commercial support? Inquire at support(a)linaro.org
-- Michael
All,
In the below code, I tried few compiler options and got following observations:
1) arm-linux-gnueabi-gcc -O2 -mcpu=cortex-a15 -mfpu=neon -ftree-vectorizer-verbose=6 -ftree-vectorize
Compiler throws following info messages:
foo.c:16: note: not vectorized: unsupported use in stmt.
foo.c:16: note: not vectorized: unsupported use in stmt.
foo.c:18: note: not vectorized: unsupported use in stmt.
foo.c:18: note: not vectorized: unsupported use in stmt.
2) -O2 -mcpu=cortex-a15 -mfpu=neon
None of the generated code contains the NEON instructions. Code generated with case 1 is taking 3000 cycles, and code generated by option 2 is taking 2500 cycles.
Even if vectorization failed in case1, it should not generate more inefficient code than case 2. My belief was that the executables from both would take same cycles, any thing done for doing unsuccessful vectorization must be reverted if it did not succeed.
###################################################################
#define SIZE1 20
#define SIZE2 26
unsigned int array[SIZE1][SIZE2];
void foo()
{
unsigned int i,j;
unsigned int max = 0;
for(i = 0; i < SIZE1; i++)
{
for(j = 0; j < SIZE2; j++)
{
if (array[i][j] > max)
{
max = array[i][j];
index = j;
}
}
}
printf("Max value: %u Index: %u\n", max, index);
}
Regards
RKS
Hi there. The 2012.04 toolchain release is this week.
Ulrich, I see your fix for LP: #968766 has been approved upstream. In
theory it's too late but I'm happy to land it if you are. Could you
decide and let Andrew know by the middle of Tuesday? Andrew, if you
don't hear from Ulrich then spin away.
Andrew, could you run the release process on Tuesday please? There's
one extra step this month: once you've uploaded and spawned the job,
go to the scheduler screen and click on 'Release' beside each of the
ursas. I reserved them to make sure they'd be idle and ready to pick
up the release build when ready.
Thiago, let us know if Ulrich or I can lend a hand with the GDB release.
-- Michael
Hi there,
At the last call Michael asked if we could push this call back by 30
minutes given the changes due to daylight savings. Does anyone have
any objections to a new time of 10 a.m. BST - 11 a.m. Central
European - 9 p.m. New Zealand. ?
cheers
Ramana
* GCC
Identified the latent bug that's upset my NEON-shifts testing. It turns
out the define-insn-and-shift patterns in arm/sync.md have no length
attributes set.
Now that the NEON 64-bit shifts appear to be not broken, I've relaunched
the 64-bit extend testing.
Identified the problem with my NEON-64-bit-negate patch: I already knew
it works better (produces more optimal code) with my NEON-immediates
patch, but it turns out that at -O0 the other patch is a hard
requirement or else bad things happen in output_move_vfp.
Backported Ramana's patch for ARM-mode testing of my recent Thumb 64-bit
test cases. I've applied it to Linaro GCC directly, without a merge
proposal, as it's a very low-risk patch.
Caught up with some launchpad blueprint fiddling.
Completed the merges from 4.6 and 4.7 FSF. The 4.7 merge was tricky as
it required working around a BZR bug; I've posted the workaround to the
toolchain list.
* Other
On leave on Tuesday
Public holiday on Friday.
Attached a copy of the ARM Linux ABI document to KBentry 39 so we're
hosting it somewhere, at least. Posted an internal Mentor/CS question
about getting its old home restored, and getting a relicensed edition to
allow others to use it as the basis for a hard-float equivalent.
=== Progress ===
* Worked on VFP addressing patch and corrected the failures.
* Got SPEC2k up and running with hot cold partitioning. Some SEGVs
that need investigation. In
general results appear to be better in quite a few cases.
* Investigated an issue with a merge request for upstream 4.7 branch
into our tree. There was a testsuite
failure and I wasn't able to reproduce it with a local i386 rebuild of
the toolchain. Therefore we'll have to
let this go in.
== Plans ==
* I will be away for 2 days this week attending the LLVM conference in London.
* Pursue backporting gnu_unique_object upstream.
* Finish off the VFP addressing modes patch upstream.
* Look at some of the existing blueprints and start discussions around
prioritizing this.
* Investigate some of the SEGVs with h-c partitioning.
Absences.
* Apr 12-13 : Euro-LLVM London.
* Linaro Connect Q2.12 - May 28 - June 1 -
Summary:
* Revise the patch for relocatable NLS support.
* Code size benchmark analysis.
Details:
1. Revise the patch for relocatable NLS support: lp:918926.
* Read the gcc configure and makefile.
* It seams hard to get the relative dir if the gcc is configured
with --bindir=... --datadir/datarootdir. E.g.
--bindir=/opt/bin
--datarootdir=/tmp/data
2. Code size benchmark analysis with -Os
* Investigate regression in small cases.
3. Try to build linaro gcc trunk with crosstool-ng. But it reports
error when configuring libquadmath.
* configure:9829: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
* Manual check or a simple case show libc.so can be linked.
Plans:
* Tuning optimization heuristics for -Os
Planed leaves:
* April 9 - 11: Vacations
Best regards!
-Zhenqiang
