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

            Bug ID: 59393
           Summary: [4.8/4.9 regression] mips16 code size
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sandra at codesourcery dot com

Created attachment 31383
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31383&action=edit
bf_enc.i

The attached test case (part of blowfish) is compiled for MIPS16 with

-Os -DNDEBUG -fno-schedule-insns2  -mno-check-zero-division -fno-common 
-fsection-anchors -fno-shrink-wrap -ffunction-sections -mips16

In GCC 4.7, this produced 2152 bytes of code.

In GCC 4.8, it produces 2396 bytes.  On mainline head, it's 2384.  In both
cases, the code growth is coming from reload blowing up.

I tracked the 4.8 regression down to two distinct changes:

(1) This patch for PR54109
http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00617.html
removed forward-propagation of constant offsets into address expressions.  No
subsequent pass is making that optimization so the code requires one extra
register that is live essentially through the whole function by the time it
gets to reload.

(2) The hoist pass seems to be significantly underestimating register pressure
and adds 9 more pseudos with long lifetimes.  (This might be a red herring, but
why is it only considering GR_REGS as a pressure class and not M16_REGS?)

By reverting the above patch and disabling the hoist pass, I was able to get
the same code size on 4.8 as 4.7.  On mainline head, there's something else
going on as well, as this brought the code size down only halfway, to 2280
bytes.  I haven't yet analyzed where the remaining bad code is coming from, but
if I had to make a wild stab in the dark, I'd guess that if the register
pressure calculation is wrong in hoist it may be wrong in other places as well.

In any case, reverting a patch that fixes a correctness bug and disabling the
hoist pass is clearly not an acceptable solution.  Any suggestions on the
"right" way to fix the two already-identified problems?

Reply via email to