After merging ARCompact support into gcc 4.4.0 20081210, we noticed that
cycle count is up by 155% compared to gcc 4.2.1 for ARC700 on the eembc
bitmnp01
benchmark. There are long sequences of putting integer constants on the stack,
and shufflink stack locations / registers around in the inner loop.
The *084t.pre dump shows that partial redundancy elimination / constant
propagation has gone berserk, calculating combined ORed values through
all the paths of the sequence of ifs in the main loop.
I've built an i686-pc-linux-gnu compiler from the same sources and
verified that the 084t.pre dump and the .s file show the same bogosity.
(Using options -O3 -fomit-frame-pointer -gstabs -fdump-tree-all. )
I've confirmed the same findings for i686-pc-linux-gnu with a pristine
svn snapshot from today, Revision: 143207.
--
Summary: huge performance regression on EEMBC bitmnp01
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: amylaar at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
