Files
Christophe Leroy 665151f591 asm-generic: force inlining of get_order() to work around gcc10 poor decision
When building mpc885_ads_defconfig with gcc 10.1,
the function get_order() appears 50 times in vmlinux:

 [linux]# ppc-linux-objdump -x vmlinux | grep get_order | wc -l
 50

 [linux]# size vmlinux
    text	   data	    bss	    dec	    hex	filename
 3842620	 675624	 135160	4653404	 47015c	vmlinux

In the old days, marking a function 'static inline' was forcing GCC to
inline, but since commit ac7c3e4ff401 ("compiler: enable
CONFIG_OPTIMIZE_INLINING forcibly") GCC may decide to not inline a
function.

It looks like GCC 10 is taking poor decisions on this.

get_order() compiles into the following tiny function, occupying 20
bytes of text.

 0000007c <get_order>:
   7c:   38 63 ff ff     addi    r3,r3,-1
   80:   54 63 a3 3e     rlwinm  r3,r3,20,12,31
   84:   7c 63 00 34     cntlzw  r3,r3
   88:   20 63 00 20     subfic  r3,r3,32
   8c:   4e 80 00 20     blr

By forcing get_order() to be __always_inline, the size of text is
reduced by 1940 bytes, that is almost twice the space occupied by
50 times get_order()

 [linux-powerpc]# size vmlinux
    text	   data	    bss	    dec	    hex	filename
 3840680	 675588	 135176	4651444	 46f9b4	vmlinux

Link: https://lkml.kernel.org/r/96c6172d619c51acc5c1c4884b80785c59af4102.1602949927.git.christophe.leroy@csgroup.eu
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Cc: Segher Boessenkool <segher@kernel.crashing.org>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Yaroslav Furman <yaro330@gmail.com>
Signed-off-by: Jebaitedneko <Jebaitedneko@gmail.com>
Signed-off-by: Pranav Vashi <neobuddy89@gmail.com>
2024-06-06 15:41:08 +03:00
..
2021-08-16 12:27:20 +00:00
2021-08-16 12:27:20 +00:00
2018-05-30 07:52:00 +02:00
2021-08-16 12:27:20 +00:00
2021-08-16 12:27:20 +00:00
2021-08-16 12:27:20 +00:00
2021-08-16 12:27:20 +00:00
2022-01-22 14:28:43 +00:00