[Bug tree-optimization/38785] New: huge performance regression on EEMBC bitmnp01

["amylaar at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

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