Daylight savings changes
Hi toolchain people, I've gone through and massaged our meetings and 1-on-1s to handle the recent daylight savings changes. Most meetings now start at 9:15 am GMT and 1-on-1s are packed before them if possible. Let me know if I should massage them further, -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [ACTIVITY] report week 44
On 5 November 2012 12:04, Peter Maydell wrote: > * Attended Linaro Connect; notable sessions: >+ Ubuntu plans for QEMU for Ringtail release > = upstream qemu has merged qemu-kvm back in so > Ubuntu will switch to qemu from qemu-kvm for x86 > = also makes sense now to use upstream qemu for all archs > (following Debian) rather than using qemu-linaro for non-x86: > reasons for using q-l in Ubuntu now mostly fixed (ie upstream > ARM support no longer dire). Ubuntu will carry omap3 patches > to avoid dropping that feature in the changeover > = makes sense for Linaro too as we now have an automated > package-to-PPA setup for people who need bleeding-edge and > also will want Ubuntu to transition to a more stably released > and supported QEMU codebase to use for KVM-on-ARM-servers > I'm happy with that as: * One project for all arches is best * Linaro QEMU has a more bleeding edge approach than Linaro GCC * Upstream QEMU has a nice, short release cycle * We have a daily builds PPA I'd like to add our monthly releases to a PPA for those who want to pick it up. + KVM Testing plans > = worked through a list of things that would be nice to test; > useful feedback from people in the session about what matters. > Missing: specific commitment by anybody to write tests :-) > This is our (yet to be met) QA team. FYI, I've archived the Etherpad notes out at: https://wiki.linaro.org/WorkingGroups/ToolChain/Connect/Q4.12Archive -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [PATCH] ARM: decompressor: clear SCTLR.A bit for v7 cores
On 6 November 2012 02:48, Rob Herring wrote:
>
> On 11/05/2012 05:13 AM, Russell King - ARM Linux wrote:
> > On Mon, Nov 05, 2012 at 10:48:50AM +, Dave Martin wrote:
> >> On Thu, Oct 25, 2012 at 05:08:16PM +0200, Johannes Stezenbach wrote:
> >>> On Thu, Oct 25, 2012 at 09:25:06AM -0500, Rob Herring wrote:
> On 10/25/2012 09:16 AM, Johannes Stezenbach wrote:
> > On Thu, Oct 25, 2012 at 07:41:45AM -0500, Rob Herring wrote:
> >> On 10/25/2012 04:34 AM, Johannes Stezenbach wrote:
> >>> On Thu, Oct 11, 2012 at 07:43:22AM -0500, Rob Herring wrote:
> >>>
> While v6 can support unaligned accesses, it is optional and current
> compilers won't emit unaligned accesses. So we don't clear the A bit
> for
> v6.
> >>>
> >>> not true according to the gcc changes page
> >>
> >> What are you going to believe: documentation or what the compiler
> >> emitted? At least for ubuntu/linaro 4.6.3 which has the unaligned
> >> access
> >> support backported and 4.7.2, unaligned accesses are emitted for v7
> >> only. I guess default here means it is the default unless you change
> >> the
> >> default in your build of gcc.
> >
> > Since ARMv6 can handle unaligned access in the same way as ARMv7
> > it seems a clear bug in gcc which might hopefully get fixed.
> > Thus in this case I think it is reasonable to follow the
> > gcc documentation, otherwise the code would break for ARMv6
> > when gcc gets fixed.
>
> But the compiler can't assume the state of the U bit. I think it is
> still legal on v6 to not support unaligned accesses, but on v7 it is
> required. All the standard v6 ARM cores support it, but I'm not sure
> about custom cores or if there are SOCs with buses that don't support
> unaligned accesses properly.
> >>>
> >>> Well, I read the "...since Linux version 2.6.28" comment
> >>> in the gcc changes page in the way that they assume the
> >>> U-bit is set. (Although I'm not sure it really is???)
> >>
> >> Actually, the kernel checks the arch version and the U bit on boot,
> >> and chooses the appropriate setting for the A bit depending on the
> >> result. (See arch/arm/mm/alignment.c:alignment_init().)
> >
> > That is in the kernel itself, _after_ the decompressor has run. It is
> > not relevant to any discussion about the decompressor.
> >
> >> Currently, we depend on the CPU reset behaviour or firmware/
> >> bootloader to set the U bit for v6, but the behaviour should be
> >> correct either way, though unaligned accesses will obviously
> >> perform (much) better with U=1.
> >
> > Will someone _PLEASE_ address my initial comments against this patch
> > in light of the fact that it's now been proven _NOT_ to be just a V7
> > issue, rather than everyone seemingly buring their heads in the sand
> > over this.
>
> I tried adding -munaligned-accesses on a v6 build and still get byte
> accesses rather than unaligned word accesses. So this does seem to be a
> v7 only issue based on what gcc will currently produce. Copying Michael
> Hope who can hopefully provide some insight on why v6 unaligned accesses
> are not enabled.
This looks like a bug. Unaligned access is enabled for armv6 but
seems to only take effect for cores with Thumb-2. Here's a test case
both with unaligned field access and unaligned block copy:
struct foo
{
char a;
int b;
struct
{
int x[3];
} c;
} __attribute__((packed));
int get_field(struct foo *p)
{
return p->b;
}
int copy_block(struct foo *p, struct foo *q)
{
p->c = q->c;
}
With -march=armv7-a you get the correct:
bar:
ldr r0, [r0, #1]@ unaligned @ 11unaligned_loadsi/2
[length = 4]
bx lr @ 21*arm_return [length = 12]
baz:
str r4, [sp, #-4]! @ 25*push_multi [length = 4]
mov r2, r0 @ 2 *arm_movsi_vfp/1[length = 4]
ldr r4, [r1, #5]! @ unaligned @ 9 unaligned_loadsi/2
[length = 4]
ldr ip, [r1, #4]@ unaligned @ 10unaligned_loadsi/2
[length = 4]
ldr r1, [r1, #8]@ unaligned @ 11unaligned_loadsi/2
[length = 4]
str r4, [r2, #5]@ unaligned @ 12unaligned_storesi/2
[length = 4]
str ip, [r2, #9]@ unaligned @ 13unaligned_storesi/2
[length = 4]
str r1, [r2, #13] @ unaligned @ 14unaligned_storesi/2
[length = 4]
ldmfd sp!, {r4}
bx lr
With -march=armv6 you get a byte-by-byte field access and a correct
unaligned block copy:
bar:
ldrbr1, [r0, #2]@ zero_extendqisi2
ldrbr3, [r0, #1]@ zero_extendqisi2
ldrbr2, [r0, #3]@ zero_extendqisi2
ldrbr0, [r0, #4]@ zero_extendqisi2
orr r3, r3, r1, asl #8
orr r3, r3, r2, asl #16
orr r0, r3, r0, asl #24
bx lr
Re: Compilation speed of Linaro's gcc compared to e.g. Ubuntu's version
On 30 October 2012 22:11, Mans Rullgard wrote: > On 29 October 2012 16:28, "Frank Müller" wrote: >> Mans Rullgard wrote: >>> On 28 October 2012 18:08, "Frank Müller" wrote: >>> > For easier maintenance, we are now switching to Linaro. The image is set >>> up and I can compile, however I notice a peculiar fact: the binary >>> distribution of Linaro's gcc >>> (https://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2) >>> has a significantly larger compilation speed than a version of >>> arm-linux-gnueabihf-gcc that is shipping with Ubuntu. In our particular >>> case, using >>> Ubuntu's version it takes less than 6 minutes to compile our software, but >>> 10 >>> minutes when we use Linaro's version. The makefiles and source are exactly >>> the same, only the compiler is different. I also tried an older version >>> (4.6) of Linaro's gcc to match the Ubuntu one (tested the 12.04 shipped >>> version), with no significant difference. >>> > >>> > Compiler flags for the system are -march=armv7-a -mtune=cortex-a8 >>> -mfpu=neon -mfloat-abi=hard >>> >>> Could you please show us the full output from compiling one of your >>> source files adding -v to the flags with both compilers? This will >>> reveal any differences in how they were configured. >> >> Of course. I've also updated to the Ubuntu 12.10 >> g++-arm-linux-gnueabihf_4.7.2 version so it matches a bit better. For better >> readability I've added "=" lines between the outputs. > > Your Linaro compiler is a 32-bit build, the Ubuntu one 64-bit. That > might explain at least part of the difference. Hi Frank. I had a quick play and built a 64 bit version of the current release. See: http://people.linaro.org/~michaelh/incoming/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121015_linux64.tar.xz Could you give it a try under Ubuntu Precise and see if the compilation speed changes? If not we can look further. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Initial aarch64 plans
This is the first of a few Connect follow up emails. KVM and Cortex-A15 tuning are to come. Matt and I have entered the initial aarch64 blueprints. These are part of the bootstrap that clear the way for us and the community to port packages on top. The high priority ones are: * Add support for AArch64 to Boehm GC[1] * Add support for GProf to AArch64 backend of GCC[2] After those we have: * Add IFUNC support for AArch64[3] * AArch64 GCC support for Stack Protection[4] All are linked off the parent blueprint at: https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-initial-meta and we'll add more there as time goes by. The plan is to commit to the first two and do them this iteration. The latter two aren't critical and will be done as part of our general work. -- Michael [1] https://launchpad.net/linaro-toolchain-misc/+spec/aarch64-boehm-gc [2] https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-gprof-support [3] https://launchpad.net/binutils-linaro/+spec/aarch64-gcc-ifunc [4] https://launchpad.net/gcc-linaro/+spec/aarch64-gcc-ssp-support ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Compilation speed of Linaro's gcc compared to e.g. Ubuntu's version
Hi Michael Hope > On 30 October 2012 22:11, Mans Rullgard wrote: > > On 29 October 2012 16:28, "Frank Müller" wrote: > >> Mans Rullgard wrote: > >>> On 28 October 2012 18:08, "Frank Müller" wrote: > >>> > For easier maintenance, we are now switching to Linaro. The image is > set > >>> up and I can compile, however I notice a peculiar fact: the binary > >>> distribution of Linaro's gcc > >>> > (https://launchpad.net/linaro-toolchain-binaries/trunk/2012.10/+download/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121022_linux.tar.bz2) > >>> has a significantly larger compilation speed than a version of > >>> arm-linux-gnueabihf-gcc that is shipping with Ubuntu. In our > particular case, using > >>> Ubuntu's version it takes less than 6 minutes to compile our software, > but 10 > >>> minutes when we use Linaro's version. The makefiles and source are > exactly > >>> the same, only the compiler is different. I also tried an older > version > >>> (4.6) of Linaro's gcc to match the Ubuntu one (tested the 12.04 > shipped > >>> version), with no significant difference. > >>> > > >>> > Compiler flags for the system are -march=armv7-a -mtune=cortex-a8 > >>> -mfpu=neon -mfloat-abi=hard > >>> > >>> Could you please show us the full output from compiling one of your > >>> source files adding -v to the flags with both compilers? This will > >>> reveal any differences in how they were configured. > >> > >> Of course. I've also updated to the Ubuntu 12.10 > g++-arm-linux-gnueabihf_4.7.2 version so it matches a bit better. For better > readability I've > added "=" lines between the outputs. > > > > Your Linaro compiler is a 32-bit build, the Ubuntu one 64-bit. That > > might explain at least part of the difference. > > Hi Frank. I had a quick play and built a 64 bit version of the > current release. See: > > http://people.linaro.org/~michaelh/incoming/gcc-linaro-arm-linux-gnueabihf-4.7-2012.10-20121015_linux64.tar.xz > > Could you give it a try under Ubuntu Precise and see if the > compilation speed changes? If not we can look further. I tried your 64 bit version and got a compilation time of 11m5.699s. So the updated "benchmark" overview is now 6m24s/4.6mb gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) 7m2s/4.0mb gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-1ubuntu1) 10m51s/4.0mbgcc version 4.7.3 20121001 (prerelease) 32 bit 11m3s/4.2mb same (4.7.3/Linaro) but with -mtune=cortex-a9 11m5s/4.0mb gcc version 4.7.3 20121001 (prerelease) 64 bit Has anybody done any performance comparisons with the two compilers (Ubuntu vs Linaro)? Should I try to make an example project that exhibits this "problem"? Frank ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
