GCC Bugzilla Bug 11821

If the C source code contains an operator which doesn't have a machine code
instruction but has a library implementation (such as % and /) and the second
operand is a constant, then GCC inserts an inline implementation of the operator
into the assembly code (example_1) rather than a function call (example_2) to
the library routine (e.g. __modsi3). In a general case the appropriate function
call is generated.
GCC should avoid operator inlining in the case when optimizing for size.

--- c example_1 ---
// arm-elf-gcc -S -g0 -Os -o func-in-1.s func-in-1.c
int a;
int foo ()
{
  return (a % 5);
} 
--- c example_2 ---
// arm-elf-gcc -S -g0 -Os -o func-in-2.s func-in-2.c
int a;
int foo ()
{
  return (12 % a);
}

--- arm code example_1 ---
foo:
 ldr r3, .L2
 ldr r2, [r3, #0]
 ldr r3, .L2+4
 smull r1, r3, r2, r3
 mov r0, r2, asr #31
 rsb r0, r0, r3, asr #1
 add r0, r0, r0, asl #2
 rsb r0, r0, r2
 mov pc, lr 

--- arm code example_2 ---
foo:
 mov ip, sp
 stmfd sp!, {fp, ip, lr, pc}
 ldr r3, .L2
 sub fp, ip, #4
 ldr r1, [r3, #0]
 mov r0, #12
 bl __modsi3
 ldmea fp, {fp, sp, pc}

I agrue but sometimes it does increase the size so ..

and this cannot be done with the current infrustructor of gcc so suspending it.

The reason why I say it is because size counting (in the backend or in the
middle-end) is not 
implemented but needs to be for optimizing size to be better.

Actually the problem was that the arm backend did not take into account
optimize for size at all 
but now this is fixed on the mainline and will be fixed for 3.4.