> 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?
> 

Hi,

Thanks for having a look! I think the Richards are exploring a different 
solution on the PR
so I don't think it's worth looking at now (maybe in stage-1?).  Thanks for 
checking though!

I Appreciate you all helping to get this fixed!

Kind Regards,
Tamar

> (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

Reply via email to