[Bug rtl-optimization/108595] New: -fcall-saved-a1 with -O2 leads to incorrect RISC-V code-gen around inline assembly

[Bug rtl-optimization/108595] New: -fcall-saved-a1 with -O2 leads to incorrect RISC-V code-gen around inline assembly

[idan.horowitz at gmail dot com]

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

            Bug ID: 108595
           Summary: -fcall-saved-a1 with -O2 leads to incorrect RISC-V
                    code-gen around inline assembly
           Product: gcc
           Version: 12.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: idan.horowitz at gmail dot com
  Target Milestone: ---

Created attachment 54370
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54370&action=edit
preprocessed reproducer

The attached code snippet compiled with `-fcall-saved-a1` (which is usually a
caller-saved register) and `-O2` erroneously saves/restores `a1` around the
inline assembly, as if it's a function call. Since GCC allocates `a1` for the
use of the inline assembly, this means that the result of the inline assembly
is clobbered. Note that this issue does not happen with `-O0` or `-O1`, so it
sounds like an optimizer issue to me.

GCC information:
Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/riscv64/gcc-12.2.0/riscv64-unknown-linux-gnu/bin/riscv64-unknown-linux-gnu-gcc
Target: riscv64-unknown-linux-gnu
Configured with: /opt/.build/riscv64-unknown-linux-gnu/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=riscv64-unknown-linux-gnu
--prefix=/opt/compiler-explorer/riscv64/gcc-12.2.0/riscv64-unknown-linux-gnu
--exec_prefix=/opt/compiler-explorer/riscv64/gcc-12.2.0/riscv64-unknown-linux-gnu
--with-sysroot=/opt/compiler-explorer/riscv64/gcc-12.2.0/riscv64-unknown-linux-gnu/riscv64-unknown-linux-gnu/sysroot
--enable-languages=c,c++,fortran,ada,d,objc,obj-c++,go --with-arch=rv64gc
--with-abi=lp64d --with-pkgversion='crosstool-NG UNKNOWN' --enable-__cxa_atexit
--enable-libmudflap --enable-libgomp --enable-libssp --enable-libquadmath
--enable-libquadmath-support --disable-libsanitizer --disable-libmpx
--with-gmp=/opt/.build/riscv64-unknown-linux-gnu/buildtools
--with-mpfr=/opt/.build/riscv64-unknown-linux-gnu/buildtools
--with-mpc=/opt/.build/riscv64-unknown-linux-gnu/buildtools
--with-isl=/opt/.build/riscv64-unknown-linux-gnu/buildtools --enable-lto
--enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls
--disable-multilib
--with-local-prefix=/opt/compiler-explorer/riscv64/gcc-12.2.0/riscv64-unknown-linux-gnu/riscv64-unknown-linux-gnu/sysroot
--enable-long-long
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (crosstool-NG UNKNOWN) 

The code itself is very short, but the `stdint.h` and `stddef.h` headers make
the preprocessed file pretty large, so it's attached.

Godbolt link which encompasses all of the above:
https://godbolt.org/z/h7rnGcqGh

[Bug target/108595] -fcall-saved-a1 with -O2 leads to incorrect RISC-V code-gen around inline assembly

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
a1 is also used for argument passing so is this option to use here?
What happens at -O1 ? Is it only related to sibcalls?

[Bug target/108595] -fcall-saved-a1 with -O2 leads to incorrect RISC-V code-gen around inline assembly

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It is related to sibcalls and aarch64 with x1 has the same issue.

I am suspecting this is just an invalid option to use here.

[Bug target/108595] -fcall-saved-a1 with -O2 leads to incorrect RISC-V code-gen around inline assembly

[idan.horowitz at gmail dot com]

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

--- Comment #3 from Idan Horowitz <idan.horowitz at gmail dot com> ---
(In reply to Andrew Pinski from comment #2)
> I am suspecting this is just an invalid option to use here.

a1 is indeed used for argument passing, it's used to pass the second argument.
I don't think the GCC documentation forbids using `fcall-saved` for
caller-saved argument registers, only for the return value register. (a0)

I'm using this on a boundary where the caller function assumes it can re-use
the the argument registers (a1-a7) without saving them. This has been working
fine for more than a year at this point - this is just the first time I tried
using an asm statement, so also the first time I encountered this issue.

It's not obvious to me why GCC even save/restores it around the asm statement
based on this option, since it's not a function call boundary.

[Bug target/108595] -fcall-saved-a1 with -O2 leads to incorrect RISC-V code-gen around inline assembly

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Dup of bug 60008.
See bug 60008 comment #2 on why.

*** This bug has been marked as a duplicate of bug 60008 ***