[Bug target/57002] New: ARM back end has extra entries in attribute interrupt array.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002 Bug #: 57002 Summary: ARM back end has extra entries in attribute interrupt array. Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: bpringlem...@gmail.com http://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/arm/arm.c;hb=HEAD line 2196 and 2197 are not needed. They are repeated from lines 2194 and 2195.
[Bug target/57002] ARM back end has extra entries in attribute interrupt array.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57002
--- Comment #1 from Bill Pringlemeir 2013-04-18
22:40:40 UTC ---
static const isr_attribute_arg isr_attribute_args [] =
{
{ "IRQ", ARM_FT_ISR },
{ "irq", ARM_FT_ISR },
{ "FIQ", ARM_FT_FIQ },
{ "fiq", ARM_FT_FIQ },
{ "ABORT", ARM_FT_ISR },
-- { "abort", ARM_FT_ISR },
-- { "ABORT", ARM_FT_ISR },
{ "abort", ARM_FT_ISR },
{ "UNDEF", ARM_FT_EXCEPTION },
{ "undef", ARM_FT_EXCEPTION },
{ "SWI", ARM_FT_EXCEPTION },
{ "swi", ARM_FT_EXCEPTION },
{ NULL,ARM_FT_NORMAL }
};
[Bug target/11824] [ARM] Parameter passing via stack could be improved
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11824 Bill Pringlemeir changed: What|Removed |Added CC||bpringlemeir at gmail dot ||com --- Comment #4 from Bill Pringlemeir 2013-04-20 13:59:19 UTC --- As far as I understand, the instruction stream is smaller, but there are two extra memory writes to adjust the stack. This optimization is only important for '-Os'. Generally, it will slow the code as data writes and code fetches are generally the same cost and this trades 2 for 1.
[Bug rtl-optimization/17838] spills are not re-used
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17838
Bill Pringlemeir changed:
What|Removed |Added
CC||bpringlemeir at gmail dot
||com
--- Comment #12 from Bill Pringlemeir
2013-04-20 15:47:36 UTC ---
(In reply to comment #11)
> Note that using -O3 for embedded targets isn't recommended; use -Os instead.
In this case the code is computationally intensive. It doesn't make sense to
compile with '-Os' for cryptographic algorithms.
However, I think that a performance increase can be achieved by working with
gcc. I have worked on an ARM project where two different developers choose
'TomsFastMath' and 'libgcrypt' as a crypto-base. It seems that 'libgcrypt' was
performing better on the ARM. I believe this is because it used 'gcc' inline
assembler to map op-codes not available in 'C'. Gcc's inline assembler is very
nice as you don't have to do register allocation and all the other nice things
that 'gcc' does for us.
http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgcrypt.git;a=blob;f=mpi/longlong.h;hb=HEAD
The use of the carry bit for multi-precision arithmetic gives a large advantage
for algorithms such as RSA cites as being worse with ARMcc versus 'gcc' on the
ARM.
For the original issue which the bug was filed (x86 sha), I can understand your
frustration. I also tried to expand the SHA to handle 64 bits at a time as you
have done with MMX ('__builtin_ia32_pslld', etc). It is difficult to get this
to work with 'gcc'; I only had a 30% speed up versus 32bit versions.
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 Bill Pringlemeir changed: What|Removed |Added CC||bpringlemeir at gmail dot com --- Comment #22 from Bill Pringlemeir --- The good ARM assembler uses the 'mla' instruction which is a 'multiply and accumulate'. Since this is not recognized, the multiply result needs a temporary register to do the add with and I think this cause the extra registers. I believe you should look to see why the 'mla' is not matched. I don't know if the x86 has an op-code like this.
[Bug tree-optimization/60172] [4.9/4.10 Regression] ARM performance regression from trunk@207239
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60172 --- Comment #23 from Bill Pringlemeir --- (In reply to Bill Pringlemeir from comment #22) > The good ARM assembler uses the 'mla' instruction which is a 'multiply and > accumulate'. Since this is not recognized, the multiply result needs a > temporary register to do the add with and I think this cause the extra > registers. I believe you should look to see why the 'mla' is not matched. > I don't know if the x86 has an op-code like this. Er, I see. The 'mla' comes as a result of seeing that the array index calculations can be reused. Sorry for the noise.
[Bug lto/47527] [4.6 regression] -flto -flto-partition=none broken for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47527
Bill Pringlemeir changed:
What|Removed |Added
CC||bpringlemeir at gmail dot
||com
--- Comment #6 from Bill Pringlemeir 2011-04-14
16:03:01 UTC ---
I have a similar compiler, gcc 4.6 for an arm linux eabi tls target with
binutils-2.21. A simple program in mplayer configure was failing.
[start shell log]
bpringlemeir@ps-bpringlemeir1:~/nbs/ltib$
~/x-tools/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -flto -o tmp.x
tmp.c
/home/bpringlemeir/x-tools/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.6.0/../../../../arm-none-linux-gnueabi/bin/ld:
error: Source object /tmp/ccclnYhZ.o.ironly has EABI version 0, but target
tmp.x has EABI version 5
/home/bpringlemeir/x-tools/arm-none-linux-gnueabi/lib/gcc/arm-none-linux-gnueabi/4.6.0/../../../../arm-none-linux-gnueabi/bin/ld:
failed to merge target specific data of file /tmp/ccclnYhZ.o.ironly
collect2: ld returned 1 exit status
bpringlemeir@ps-bpringlemeir1:~/nbs/ltib$ cat tmp.c
#include
int main(void) { return 0; }
bpringlemeir@ps-bpringlemeir1:~/nbs/ltib$
~/x-tools/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc -v
Using built-in specs.
COLLECT_GCC=/home/bpringlemeir/x-tools/arm-none-linux-gnueabi/bin/arm-none-linux-gnueabi-gcc
COLLECT_LTO_WRAPPER=/home/bpringlemeir/x-tools/arm-none-linux-gnueabi/libexec/gcc/arm-none-linux-gnueabi/4.6.0/lto-wrapper
Target: arm-none-linux-gnueabi
Configured with:
/home/bpringlemeir/crosstool-arm-4.6/targets/src/gcc-4.6.0/configure
--build=x86_64-build_unknown-linux-gnu --host=x86_64-build_unknown-linux-gnu
--target=arm-none-linux-gnueabi
--prefix=/home/bpringlemeir/x-tools/arm-none-linux-gnueabi
--with-sysroot=/home/bpringlemeir/x-tools/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot
--enable-languages=c,c++ --disable-multilib --with-arch=armv5te
--with-cpu=arm926ej-s --with-tune=arm926ej-s --with-float=soft
--with-pkgversion=crosstool-NG-hg_default@2370_e915ac8a4224
--enable-__cxa_atexit --disable-libmudflap --disable-libgomp --enable-libssp
--with-gmp=/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static
--with-mpfr=/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static
--with-mpc=/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static
--with-ppl=/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static
--with-cloog=/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static
--with-libelf=/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static
--with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm
-L/home/bpringlemeir/crosstool-arm-4.6/targets/arm-none-linux-gnueabi/build/static/lib
-lpwl' --enable-threads=posix --enable-target-optspace --enable-plugin
--enable-gold
--with-local-prefix=/home/bpringlemeir/x-tools/arm-none-linux-gnueabi/arm-none-linux-gnueabi/sysroot
--disable-nls --enable-symvers=gnu --enable-c99 --enable-long-long
Thread model: posix
gcc version 4.6.0 (crosstool-NG-hg_default@2370_e915ac8a4224)
[end shell log]
I thought I had patched the linker, but I didn't... I will rebuild again.
[Bug lto/47527] [4.6 regression] -flto -flto-partition=none broken for arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47527
--- Comment #7 from Bill Pringlemeir 2011-04-14
17:37:27 UTC ---
After applying the patch, the tmp.c files builds without issues.
#include
int main(void) { return 0; }
$ arm-none-linux-gnueabi-gcc -flto -o tmp.x
tmp.c
It seems to be the same issues as Ramana has reported. Also my compiler has
eglibc... but I think this is a binutils/ld issue. Did you want any more
confirmation?
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159 Bill Pringlemeir changed: What|Removed |Added CC||bpringlemeir at gmail dot ||com --- Comment #9 from Bill Pringlemeir 2011-04-14 21:57:23 UTC --- I believe I also have this occurring with host=x86_64-linux target=arm-linux-gnueabi. After reading this ticket, I retried my compiles with the same link and compile optimization level and it succeeds. I understand that you want gcc to support different option levels for both compile and link. However, I don't know that most people want this and I am not use to passing the linker options; a diagnostic for ld/gold plug-in when there is an optimization mismatch may be helpful? Is that a possibility for 4.5.x and 4.6.x releases?
[Bug lto/41159] [LTO] ICE in insert_value_copy_on_edge, at tree-outof-ssa.c:225
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41159 --- Comment #10 from Bill Pringlemeir 2011-04-14 22:00:18 UTC --- (In reply to comment #9) > .. I am not use to passing the linker options err ... optimization options.
