https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30354
--- Comment #17 from Denis Vlasenko <vda.linux at googlemail dot com> ---
Any chance of this being finally done?
I proposed a simple, working patch in 2007, it's 2016 now and all these years
users of -Os suffer from slow divisions in important cases usch as "signed_int
/ 16" and "unsigned_int / 10".
I understand your desire to do it "better", to make gcc count size of div/idiv
more accurately, without having to lie to it in the insn size table. But with
you guys constantly distracted by other, more important issues, what happened
here is that _nothing_ was done...
I retested the patch with current svn (the future 7.0.0), using test program
with 15000 divisions from comment 3:
Bumping division cost up to 8 is no longer enough, this only makes gcc to be
better towards some (not all) 2^N divisors. Bumping div cost to 9..12 helps
with most of remaining 2^N divisor cases, and for two exceptional cases of x /
641 and x / 6700417. Only bumping div cost to 13, namely, changing div costs as
follows:
const
struct processor_costs ix86_size_cost = {/* costs for tuning for size */
...
{COSTS_N_BYTES (13), /* cost of a divide/mod for QI */
COSTS_N_BYTES (13), /* HI */
COSTS_N_BYTES (13), /* SI */
COSTS_N_BYTES (13), /* DI */
COSTS_N_BYTES (15)}, /* other */
makes it work as it used to in 4.4.x days: out of 15000 cases in t.c, 975 cases
are optimized so that they don't use "div" anymore.
This should have made it smaller too... but did not, because meanwhile gcc has
regressed in another area. Now it inserts superfluous register moves. See bug
70703 which I just filed. Essentially, instead of
movl $6700417, %eax
mull 4(%esp)
movl %edx, %eax
ret
gcc generates:
movl $6700417, %ecx
movl %ecx, %eax ????
mull 4(%esp)
movl %edx, %ecx ????
movl %ecx, %eax
ret
Sizes of compiled testcases (objN denotes cost of "div", A...D correspond to
costs of 10..13):
text data bss dec hex filename
242787 0 0 242787 3b463 gcc.obj3/divmod-7.0.0-Os.o
242813 0 0 242813 3b47d gcc.obj8/divmod-7.0.0-Os.o
242838 0 0 242838 3b496 gcc.obj9/divmod-7.0.0-Os.o
242844 0 0 242844 3b49c gcc.objA/divmod-7.0.0-Os.o
242844 0 0 242844 3b49c gcc.objB/divmod-7.0.0-Os.o
242844 0 0 242844 3b49c gcc.objC/divmod-7.0.0-Os.o
247573 0 0 247573 3c715 gcc.objD/divmod-7.0.0-Os.o
So.
Any chance of this patch being accepted sometime before 2100? ;)
