[Bug target/50883] New: [ARM] Suboptimal optimization for small structures

[Bug target/50883] New: [ARM] Suboptimal optimization for small structures

[sebastian.huber@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

             Bug #: 50883
           Summary: [ARM] Suboptimal optimization for small structures
    Classification: Unclassified
           Product: gcc
           Version: 4.6.2
            Status: UNCONFIRMED
          Severity: enhancement
          Priority: P3
         Component: target
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: sebastian.huber@embedded-brains.de
            Target: arm-eabi-gcc


Compared to PowerPC the optimization for the attached test case is suboptimal.

Command line:

arm-eabi-gcc -O2 -march=armv7-m -mthumb -S test-1.c -o test-1-arm.s
powerpc-rtems4.11-gcc -O2 -S test-1.c -o test-1-ppc.s

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.huber@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #3 from Sebastian Huber <sebastian.huber@embedded-brains.de> 2011-10-27 11:55:32 UTC ---
Created attachment 25630
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25630
PowerPC assembler.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.huber@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #1 from Sebastian Huber <sebastian.huber@embedded-brains.de> 2011-10-27 11:54:31 UTC ---
Created attachment 25628
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25628
Sample code.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.huber@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #2 from Sebastian Huber <sebastian.huber@embedded-brains.de> 2011-10-27 11:55:05 UTC ---
Created attachment 25629
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25629
ARM assembler.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2011-10-27
     Ever Confirmed|0                           |1

--- Comment #4 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-27 14:50:40 UTC ---
And so we have to find out ourselves what you think is suboptimal?  Please
explain what you expect instead.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.huber@embedded-brains.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #5 from Sebastian Huber <sebastian.huber@embedded-brains.de> 2011-10-27 15:19:57 UTC ---
If we look at the function f (the function g is similar):

struct s {
  int alignment;
  unsigned char a;
  unsigned char b;
  unsigned char c;
  unsigned char d;
};

unsigned f(struct s x)
{
  return x.a | (x.b << 8) | (x.c << 16) | (x.d << 24);
}

Currently ARM GCC produces this:

f:
    sub    sp, sp, #8
    add    r3, sp, #8
    stmdb    r3, {r0, r1}
    ldrb    r0, [sp, #6]
    ldrb    r3, [sp, #5]
    lsls    r0, r0, #16
    ldrb    r2, [sp, #4]
    orr    r0, r0, r3, lsl #8
    ldrb    r3, [sp, #7]
    orrs    r0, r0, r2
    orr    r0, r0, r3, lsl #24
    add    sp, sp, #8
    bx    lr

According to the ARM EABI, this structure is passed in registers r0 and r1. 
The return value is in r0.  This function may be reduced to:

f:
    mov    r0, r1
    bx    lr

The PowerPC GCC performs this optimization.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rearnsha at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
                 CC|                            |rearnsha at gcc dot gnu.org

--- Comment #6 from Richard Earnshaw <rearnsha at gcc dot gnu.org> 2011-10-27 16:53:07 UTC ---
So for PPC, this seems to be a lucky side-effect of the way the PPC ABI is
defined.  On PPC the argument is passed by reference and the compiler generates
an initial load expression of X from memory (a callee copy).  The RTL
optimization passes are then (in combination with the subreg splitting code)
able to notice, somehow, that this is equivalent to the final result and to
make use of it.

On ARM the structure is passed by value and the argument expanding code
immediately tries to store a copy into the stack.  Then, rather than seeing
that this could be used from a register value it tries to work solely with the
stack copy.

I notice that neither architecture optimizes this if the struct is passed as an
address rather than by value.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palchak at google dot com

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 104372 has been marked as a duplicate of this bug. ***

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 99712 has been marked as a duplicate of this bug. ***

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #9 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
I've seen things like this with other structures passed as parameters.

Part of the problem here is that the gimple expansion does not see the argument
unpacking or understand how the parameters are passed; so this is only exposed
after lowering to RTL and we are then reliant on the less powerful RTL
optimations to get good code.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Richard Earnshaw from comment #9)
> Part of the problem here is that the gimple expansion does not see the
> argument unpacking or understand how the parameters are passed; so this is
> only exposed after lowering to RTL and we are then reliant on the less
> powerful RTL optimations to get good code.

Right, i was thinking about how we expose so of it like having a late pass
which does the splitting if it is possible. This is part of the reason why I
created the meta bug to record all of these issues in one place to make it
easier to start working on a pass like that (maybe for gcc 13 but I have so
much stuff on my plate right now).

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #10)
> (In reply to Richard Earnshaw from comment #9)
> > Part of the problem here is that the gimple expansion does not see the
> > argument unpacking or understand how the parameters are passed; so this is
> > only exposed after lowering to RTL and we are then reliant on the less
> > powerful RTL optimations to get good code.
> 
> Right, i was thinking about how we expose so of it like having a late pass
> which does the splitting if it is possible. This is part of the reason why I
> created the meta bug to record all of these issues in one place to make it
> easier to start working on a pass like that (maybe for gcc 13 but I have so
> much stuff on my plate right now).

Btw, I thought about this issue quite extensively together with Michael Matz
and it's going to be a mess, in particular on the call side.  Representing
things on GIMPLE will also be fun.  The idea for incoming arguments was
to make the "default definitions" explicit.  For aggregates that would mean
having sth like

 struct S { double x; double y; };
 void foo (struct S s)
 {
   register double s$x __asm__("%xmm0");
   register double s$y __asm__("%xmm1");
   <bb2:>
     s.x = s$x;
     s.y = s$y; 
 }

or for registers (ick)

 void foo (_Complex double z)
 {
   register double z$r __asm__("%xmm0");
   register double z$i __asm__("%xmm1");
   <bb2:>
     z_1(D) = COMPLEX_EXPR <z$r, z$i>;
 }

but it's unclear how exactly this will help if it's just done right before
RTL expansion.  It will also be fun when an aggregate is passed partly
on the stack and partly in registers.

A similar approach could work for the return.

For calls we have representational issues, esp. for the return.  Some
cases could be improved but it might also result in for example too
large lifetime of return slots if the expose those.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebotcazou at gcc dot gnu.org

--- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Btw, I thought about this issue quite extensively together with Michael Matz
> and it's going to be a mess, in particular on the call side.  Representing
> things on GIMPLE will also be fun. 

Is it really worth the hassle though for real-world code, i.e. as opposed to
toy examples, now that we have IPA-SRA and the like?

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #13 from rguenther at suse dot de <rguenther at suse dot de> ---
On Fri, 4 Feb 2022, ebotcazou at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883
> 
> Eric Botcazou <ebotcazou at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |ebotcazou at gcc dot gnu.org
> 
> --- Comment #12 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> > Btw, I thought about this issue quite extensively together with Michael Matz
> > and it's going to be a mess, in particular on the call side.  Representing
> > things on GIMPLE will also be fun. 
> 
> Is it really worth the hassle though for real-world code, i.e. as opposed to
> toy examples, now that we have IPA-SRA and the like?

I've looked at this in the context of BB vectorization which can
cause awful code when parameters / return vars are participating
and GIMPLE represents things as memory but RTL not.

But no, I don't remember any case from SPEC where it makes a difference
in the end.  Judging from the amount of duplicates we get around
parameter / return issues people do run into this.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #14 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> But no, I don't remember any case from SPEC where it makes a difference
> in the end.  Judging from the amount of duplicates we get around
> parameter / return issues people do run into this.

Yes, but I'd think on smallish/toy examples with e.g. Compiler Explorer.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #15 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
Even if the performance impact is low, it does matter when optimizing for size.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[rearnsha at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #16 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
And there are also cases where we end up with dead stack slots which can't be
removed, so there's a stack size impact as well.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[ebotcazou at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #17 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> Even if the performance impact is low, it does matter when optimizing for
> size.

Worth addressing for sure, but IMO not at expense of exposing calling
conventions and other low-level stuff in GIMPLE.

[Bug target/50883] [ARM] Suboptimal optimization for small structures

[sebastian.huber@embedded-brains.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50883

--- Comment #18 from Sebastian Huber <sebastian.huber@embedded-brains.de> ---
clang 11 produces this code for the attached test case:

clang -O2 -S -o - pr50883.c -target arm 
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
clang-11.0: warning: unknown platform, assuming -mfloat-abi=soft
        .text
        .syntax unified
        .eabi_attribute 67, "2.09"      @ Tag_conformance
        .cpu    arm7tdmi
        .eabi_attribute 6, 2    @ Tag_CPU_arch
        .eabi_attribute 8, 1    @ Tag_ARM_ISA_use
        .eabi_attribute 9, 1    @ Tag_THUMB_ISA_use
        .eabi_attribute 34, 0   @ Tag_CPU_unaligned_access
        .eabi_attribute 17, 1   @ Tag_ABI_PCS_GOT_use
        .eabi_attribute 20, 1   @ Tag_ABI_FP_denormal
        .eabi_attribute 21, 0   @ Tag_ABI_FP_exceptions
        .eabi_attribute 23, 3   @ Tag_ABI_FP_number_model
        .eabi_attribute 24, 1   @ Tag_ABI_align_needed
        .eabi_attribute 25, 1   @ Tag_ABI_align_preserved
        .eabi_attribute 38, 1   @ Tag_ABI_FP_16bit_format
        .eabi_attribute 18, 4   @ Tag_ABI_PCS_wchar_t
        .eabi_attribute 26, 2   @ Tag_ABI_enum_size
        .eabi_attribute 14, 0   @ Tag_ABI_PCS_R9_use
        .file   "pr50883.c"
        .globl  f                               @ -- Begin function f
        .p2align        2
        .type   f,%function
        .code   32                              @ @f
f:
        .fnstart
@ %bb.0:
        mov     r0, r1
        bx      lr
.Lfunc_end0:
        .size   f, .Lfunc_end0-f
        .cantunwind
        .fnend
                                        @ -- End function
        .globl  g                               @ -- Begin function g
        .p2align        2
        .type   g,%function
        .code   32                              @ @g
g:
        .fnstart
@ %bb.0:
        mov     r0, r1
        bx      lr
.Lfunc_end1:
        .size   g, .Lfunc_end1-g
        .cantunwind
        .fnend
                                        @ -- End function
        .globl  h                               @ -- Begin function h
        .p2align        2
        .type   h,%function
        .code   32                              @ @h
h:
        .fnstart
@ %bb.0:
        ldr     r1, .LCPI2_0
        ldm     r1, {r0, r1}
        b       j
        .p2align        2
@ %bb.1:
.LCPI2_0:
        .long   ss
.Lfunc_end2:
        .size   h, .Lfunc_end2-h
        .cantunwind
        .fnend
                                        @ -- End function
        .globl  i                               @ -- Begin function i
        .p2align        2
        .type   i,%function
        .code   32                              @ @i
i:
        .fnstart
@ %bb.0:
        ldr     r1, .LCPI3_0
        ldm     r1, {r0, r1}
        b       k
        .p2align        2
@ %bb.1:
.LCPI3_0:
        .long   tt
.Lfunc_end3:
        .size   i, .Lfunc_end3-i
        .cantunwind
        .fnend
                                        @ -- End function
        .ident  "clang version 11.0.1"
        .section        ".note.GNU-stack","",%progbits
        .addrsig