From: Magnus Holmgren <lear_at_algonet.se>
Date: Mon, 04 Jun 2007 19:16:12 +0200

Hi,

I had a look into why a small change to id3.h caused a large change in
binary size, and I ended up with the following patch for gcc (m68k/3.4.6):

On the ColdFire targets, the cost estimate for the multiply instructions
are not correct; they are based on CPUs without an (E)MAC unit. This
means a typical array index lookup ("a[i]") is often done using shifts
and adds, rather than multiplies (which often would be smaller and
faster). Different array element sizes needs a different mix of shifts
and adds, explaining the size difference.

At line 1593 in gcc/config/m68k.c, the following can be found (with
different wrapping):

#define MULL_COST (TARGET_68060 ? 2 : TARGET_68040 ? 5 : TARGET_CFV3 \
                    ? 3 : \ TARGET_COLDFIRE ? 10 : 13)
#define MULW_COST (TARGET_68060 ? 2 : TARGET_68040 ? 3 : TARGET_68020 \
                    ? 8 : TARGET_CFV3 ? 2 : 5)

The CPUs we build for is considered to be a TARGET_COLDFIRE. However,
the real cost is close to that of a TARGET_CFV3, so changing the above
so TARGET_COLDFIRE gets a cost of 3 and 2 respectively would be more
correct. A bit of a hack, but a proper fix requires better ColdFire
support, as provided by gcc 4.3 (which currently also has the above
problem).

Changing the above lines reduces the rockbox.iriver size with about 3 kB
here, and the code should be faster too (perhaps not in any measurable
way, but still). Maybe this patch should be considered for the build
servers?

ARM targets seem to use shifts and adds too, but I don't know if the
multiplier cost is correct there (check for the MULT case in arm.c).

   Magnus
Received on 2007-06-04