Hi!
On Sun, Mar 05, 2023 at 03:33:40PM -0600, Segher Boessenkool wrote:
> On Sun, Mar 05, 2023 at 08:43:20PM +0000, Tamar Christina wrote:
> Yes, *look* better: I have seen no proof or indication that this would
("looks", I cannot type, sorry)
> actually generate better code, not even on just aarch, let alone on the
> majority of targets. As I said I have a test running, you may be lucky
> even :-) It has to run for about six hours more and after that it needs
> analysis still (a few more hours if it isn't obviously always better or
> worse), so expect results tomorrow night at the earliest.
The results are in:
$ perl sizes.pl --percent C[12]
C1 C2
alpha 7082243 100.066%
arc 4207975 100.015%
arm 11518624 100.008%
arm64 24514565 100.067%
armhf 16661684 100.098%
csky 4031841 100.002%
i386 0 0
ia64 20354295 100.029%
m68k 4394084 100.023%
microblaze 6549965 100.014%
mips 10684680 100.024%
mips64 8171850 100.002%
nios2 4356713 100.012%
openrisc 5010570 100.003%
parisc 8406294 100.002%
parisc64 0 0
powerpc 11104901 99.992%
powerpc64 24532358 100.057%
powerpc64le 21293219 100.062%
riscv32 2028474 100.131%
riscv64 9515453 100.120%
s390 20519612 100.279%
sh 0 0
shnommu 1840960 100.012%
sparc 5314422 100.004%
sparc64 7964129 99.992%
x86_64 0 0
xtensa 2925723 100.070%
C1 is the original, C2 with your patch. These numbers are the code
sizes of a Linux kernel, some defconfig for every arch. This is a good
measure of how effective combine was.
The patch is a tiny win for sparc64 and classic powerpc32 only, but bad
everywhere else. Look at that s390 number! Or riscv, or most of the
arm variants (including aarch64).
Do you want me to look in detail what causes this regression on some
particular target, i.e. why we really still need the expand_compound
functionality there?
(Btw. "0" means the target did not build. For the x86 targets this is
just more -Werror madness that seeped in it seems. For parisc64 and sh
it is the choice of config. Will fix.)
Segher
