[Bug tree-optimization/45622] Suboptimal code generation on arm

[Bug tree-optimization/45622] Suboptimal code generation on arm

[ramana at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45622

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2010.10.04 09:15:04
                 CC|                            |ramana at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #2 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> 2010-10-04 09:15:04 UTC ---
(In reply to comment #0)
> Vorbis author, Timothy Terriberry, was complaining about gcc inefficiency on
> arm, so I asked him write it up in case it would be of use to gcc devs to
> improve gcc. Is this a useful?
> 

The description is rather useful but it would be good to have a copy of the
pre-processed file as HP says in Comment #2. It also helps so that the bug
report is self-consistent . 

What command line options are being used ? i.e. what are the architecture
specific flags ( -march= ? -mfpu= ? -mfloat-abi=? ? ) . If you use --save-temps
you can pickup the .i file .



> 
> This the result of using arm-none-linux-gnueabi-gcc (Gentoo 4.5.0 p1.1) 4.5.0
> with -O3 -fomit-frame-pointer -funroll-loops (this last makes a fairly big
> difference on x86, and so is part of the default flags for the library).

-fomit-frame-pointer is typically not required on ARM. It's one of the ABI's
that originally never had a frame pointer in normal functions and thus removing
the frame pointer doesn't make sense. 

cheers
Ramana

[Bug tree-optimization/45622] Suboptimal code generation on arm

[hp at gcc dot gnu dot org]

------- Comment #1 from hp at gcc dot gnu dot org  2010-09-20 01:57 -------
I hacked around a similar suboptimality using -fno-tree-reassoc.
(...looking...)
See PR37916 (oops! still assigned to me; the easy route I envisioned became a
dead end).

Adding a preprocessed version of huffdec.c (use -save-temps, pick up huffdec.i)
to this PR would help, I think.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45622