[cross-arm-none-eabi-gcc] / suboptimal optimization: superfluous stack write

[riddicc]

Is this a new report?

Yes

System Info

Void 6.5.5_2 x86_64 GenuineIntel uptodate hold rrrmFFF

Package(s) Affected

cross-arm-none-eabi-gcc-9.3.0_1

Does a report exist for this bug with the project's home (upstream) and/or another distro?

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

somehow my related issue #46239 gets no attention... dunno why... am i doing something wrong?

Expected behaviour

the code should be easier/faster to execute...
there are possibly much more issues, that could be fixed in the current version 13.2.0 of gcc...

Actual behaviour

it adds instructions like this:

sub     sp, sp, #16
mov     r2, sp
add     sp, sp, #16

without ever using something on the stack...

Steps to reproduce

1. install cross-arm-none-eabi-gcc
2. compile source code containing bitfield operations [[1]]
3. u will get [2]

[[1]]: source:

# 1 "a.c"
# 1 "/tmp//"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "a.c"

typedef unsigned char u8;
typedef unsigned int u32;
extern int fatal();
__attribute__((always_inline)) inline u32 lsb(const u8 l) { return (1U<<l)-1U; }

typedef struct { u32 a; u32 msk; u32 v; u8 rs:1; u8 aw:7; } Reg;
__attribute__((always_inline)) inline Reg GI(u32 A, u32 N, u32 RS, u8 AW) { Reg R={A+4*N,lsb(32),0,RS?1:0,AW}; return R; }
__attribute__((always_inline)) inline u32 GS(Reg R) {
   for (u32 i=0, msk=lsb(8); R.aw==1 && msk; i++, msk<<=8)
      if ( !~(R.msk | msk) ) {
         const u8 v = R.v >> (i*8);
         if (R.rs || msk==~R.msk) return (((volatile u8*)R.a)[i] = v) << (i*8);
         else if (R.v==~R.msk) return (((volatile u8*)R.a)[i] |= v) << (i*8);
         return (((volatile u8*)R.a)[i] = (((volatile u8*)R.a)[i] & (R.msk>>(i*8))) | v) << (i*8);
      }
 return 0;
}
__attribute__((always_inline)) inline Reg GU(Reg R, u32 A, u32 N, u8 o, u8 w, u32 v) {
   const u32 msk=~(lsb(w)<<o); R.msk&=msk; R.v&=msk;
   R.v |= (v<<o);
   return R;
}
u32 artiSP() { return GS(GU(GI(0xE0000000,42,0,1),0xE0000000,42,17,3,2)); }

[2]: resulting assembly code:

artiSP:
        sub     sp, sp, #16
        mov     r2, sp
        movs    r3, #2
        strb    r3, [r2, #12]
...
        add     sp, sp, #16
        bx      lr

[ahesford]

This is not a Void bug. The software is executing as implemented. If you want the better performance offered by a newer version, either await the update or attempt it yourself.

[riddicc]

await the update

how long will it take?

attempt it yourself

how can i become the maintainer in order to attempt it myself?

[ahesford]

It takes how ever long it takes. We're a volunteer organization, and people work on what they want, when they want.

You don't need to become a maintainer to contribute updates to packages. See the contributing guide for information on how to submit pull requests to update packages.