public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "edwintorok at gmail dot com" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug target/48789] New: missed ARM optimization: use LDMIA Date: Wed, 27 Apr 2011 11:24:00 -0000 [thread overview] Message-ID: <bug-48789-4@http.gcc.gnu.org/bugzilla/> (raw) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48789 Summary: missed ARM optimization: use LDMIA Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned@gcc.gnu.org ReportedBy: edwintorok@gmail.com Host: x86_64-linux-gnu Target: arm-elf Build: x86_64-linux-gnu The attached testcase compiles to larger and slower code than the hand-optimized version, although the C code follows closely the structure of hand-optimized assembly. To reproduce the missed optimization: arm-elf-gcc reverse.c -O3 -mcpu=arm946e-s -msoft-float The reverse_bytes_order_c2 has too many ldr/str instructions, it should use ldmia/stmia as seen in the hand-optimized version (test.S reverse_bytes_order2). Note: without -msoft-float it generates faster code by using VFP instructions, but my CPU doesn't support them, so I have to turn off floating point generation. Attachments: reverse.c: the testcase test.S: the hand-optimized version of the reverse_bytes_order_c2, called reverse_bytes_order2 here (code from CHDK's lib/armutil/) bench.c: a simple benchmark runner to compare gcc's version with the hand optimized one This happens both with 4.6 and 4.5: $ arm-elf-gcc -v Using built-in specs. COLLECT_GCC=../build-dir/arm/toolchain/bin/arm-elf-gcc COLLECT_LTO_WRAPPER=/home/edwin/chdk/build-dir/arm/toolchain/libexec/gcc/arm-elf/4.6.0/lto-wrapper Target: arm-elf Configured with: ../gcc-4.6.0/configure --target=arm-elf --prefix=/home/edwin/chdk/build-dir/arm/toolchain --enable-interwork --enable-multilib --enable-languages=c --with-newlib --with-gmp-include=/home/edwin/chdk/build-dir/build/gmp --with-gmp-lib=/home/edwin/chdk/build-dir/build/gmp/.libs --without-headers --disable-libssp --disable-nls --disable-zlib --disable-libc --disable-libm --disable-intl --disable-hardfloat --disable-threads --with-gnu-as --with-gnu-ld Thread model: single gcc version 4.6.0 (GCC) $ /opt/cfarm/release/4.5.0/bin/gcc -v Using built-in specs. COLLECT_GCC=/opt/cfarm/release/4.5.0/bin/gcc COLLECT_LTO_WRAPPER=/home/guerby/opt/release/4.5.0/bin/../libexec/gcc/armv7l-unknown-linux-gnueabi/4.5.0/lto-wrapper Target: armv7l-unknown-linux-gnueabi Configured with: ../gcc-4.5.0/configure --prefix=/opt/cfarm/release/4.5.0 --enable-languages=c,ada --enable-__cxa_atexit --disable-nls --enable-threads=posix --disable-multilib --with-gmp=/opt/cfarm/gmp-4.2.4 --with-mpfr=/opt/cfarm/mpfr-2.4.2 --with-mpc=/opt/cfarm/mpc-0.8 --with-cpu=cortex-a8 --with-fpu=neon --with-float=softfp --disable-werror Thread model: posix gcc version 4.5.0 (GCC) Some benchmarks (run on gcc33, which would support armv7, but my CPU won't, so I can only use armv5te): base: 0.340810 (hand-optimized assembly) 3: 0.840712 (alternate version) c: 0.379164 (C code, compiled with -O3) c2: 0.395410 (C code, unrolled 8 times as the hand assembly, compiled with -O3) (note: run benchmark as ./a.out; ./a.out; ./a.out. I think there is some frequency scaling causing the first run to be slower) To run benchmark: /opt/cfarm/release/4.5.0/bin/gcc bench.c reverse.c test.S -O3 -mcpu=arm946e-s -msoft-float
next reply other threads:[~2011-04-27 11:24 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2011-04-27 11:24 edwintorok at gmail dot com [this message] 2011-04-27 11:15 ` [Bug target/48789] " edwintorok at gmail dot com 2011-04-27 11:20 ` edwintorok at gmail dot com 2011-04-27 11:20 ` edwintorok at gmail dot com 2011-07-27 16:40 ` ramana at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-48789-4@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).