[PATCH] sparc/build: Make all compiler flags also clang-compatible

[PATCH] sparc/build: Make all compiler flags also clang-compatible

[Koakuma via B4 Relay]

From: Koakuma <koachan@protonmail.com>

Remove flags not supported by clang and make sure that all the flags
used are portable between clang and GCC.

The reasoning for removing the -fcall-used* ones is as follows:

In the (normal) 32-bit ABI, %g5 and %g7 is normally reserved, and in
the 64-bit ABI, %g7 is the reserved one.
Linux turns them into volatile registers by the way of -fcall-used-*,
but on the other hand, omitting the flags shouldn't be harmful;
compilers will now simply refuse to touch them, and any assembly
code that happens to touch them would still work like usual (because
Linux' conventions already treats them as volatile anyway).

Signed-off-by: Koakuma <koachan@protonmail.com>
---
Hello~

This changes the CFLAGS for building the SPARC kernel so that it can be
built with clang, as a follow up from the discussion in this thread:

https://lore.kernel.org/lkml/JAYB7uS-EdLABTR4iWZdtFOVa5MvlKosIrD_cKTzgeozCOGRM7lhxeLigFB1g3exX445I_W5VKB-tAzl2_G1zCVJRQjp67ODfsSqiZWOZ9o=@protonmail.com/T/#u

The changes are removal of various `-fcall-used-*` flags, and changing
`-mv8plus` to `-mcpu=v9`:

- `-fcall-used-*` flags should be safe to remove; the compiler will
  stop using the registers specified as temporaries, but it is a safe
  change wrt. the ABI. Assembly code can still use those registers
  as needed.
  It does bring a theoretical possible slowdown due to the compiler
  having less registers to work with, but in practice - in my case,
  at least - it seems to not make any difference with daily usage.

- More trivial is to change `-mv8plus` -> `-mcpu=v9`.
  This should be safe too since the kernel seems to require a V9
  processor to run anyway, so I'm changing the flag to one that is
  portable between GCC and clang.

Also, as stated in the thread, building with these changes still result
in a working kernel, at least for Sun T5120 and qemu virtual machines.

On the LLVM side, the effort for building Linux/SPARC is tracked here:
https://github.com/llvm/llvm-project/issues/40792
---
 arch/sparc/Makefile      | 4 ++--
 arch/sparc/vdso/Makefile | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index 757451c3ea1d..7318a8b452c3 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -29,7 +29,7 @@ UTS_MACHINE    := sparc
 # versions of gcc.  Some gcc versions won't pass -Av8 to binutils when you
 # give -mcpu=v8.  This silently worked with older bintutils versions but
 # does not any more.
-KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
+KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu
 KBUILD_CFLAGS  += -Wa,-Av8
 
 KBUILD_AFLAGS  += -m32 -Wa,-Av8
@@ -45,7 +45,7 @@ export BITS   := 64
 UTS_MACHINE   := sparc64
 
 KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
-KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
+KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -Wno-sign-compare
 KBUILD_CFLAGS += -Wa,--undeclared-regs
 KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
 KBUILD_AFLAGS += -m64 -mcpu=ultrasparc -Wa,--undeclared-regs
diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
index 243dbfc4609d..929140facabf 100644
--- a/arch/sparc/vdso/Makefile
+++ b/arch/sparc/vdso/Makefile
@@ -46,7 +46,7 @@ CFL := $(PROFILING) -mcmodel=medlow -fPIC -O2 -fasynchronous-unwind-tables -m64
        -fno-omit-frame-pointer -foptimize-sibling-calls \
        -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
 
-SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5 -fcall-used-g5 -fcall-used-g7
+SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5
 
 $(vobjs): KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS) $(GCC_PLUGINS_CFLAGS) $(SPARC_REG_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
@@ -86,7 +86,7 @@ KBUILD_CFLAGS_32 += -fno-stack-protector
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
 KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
 KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
-KBUILD_CFLAGS_32 += -mv8plus
+KBUILD_CFLAGS_32 += -mcpu=v9
 $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
 
 $(obj)/vdso32.so.dbg: FORCE \

---
base-commit: 92e5605a199efbaee59fb19e15d6cc2103a04ec2
change-id: 20240620-sparc-cflags-e7f2dbbd4b9d

Best regards,
-- 
Koakuma <koachan@protonmail.com>

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[Nathan Chancellor]

Hi Koakuma,

On Thu, Jun 20, 2024 at 10:56:00PM +0700, Koakuma via B4 Relay wrote:
> From: Koakuma <koachan@protonmail.com>
> 
> Remove flags not supported by clang and make sure that all the flags
> used are portable between clang and GCC.
> 
> The reasoning for removing the -fcall-used* ones is as follows:
> 
> In the (normal) 32-bit ABI, %g5 and %g7 is normally reserved, and in
> the 64-bit ABI, %g7 is the reserved one.
> Linux turns them into volatile registers by the way of -fcall-used-*,
> but on the other hand, omitting the flags shouldn't be harmful;
> compilers will now simply refuse to touch them, and any assembly
> code that happens to touch them would still work like usual (because
> Linux' conventions already treats them as volatile anyway).
> 
> Signed-off-by: Koakuma <koachan@protonmail.com>
> ---
> Hello~
> 
> This changes the CFLAGS for building the SPARC kernel so that it can be
> built with clang, as a follow up from the discussion in this thread:
> 
> https://lore.kernel.org/lkml/JAYB7uS-EdLABTR4iWZdtFOVa5MvlKosIrD_cKTzgeozCOGRM7lhxeLigFB1g3exX445I_W5VKB-tAzl2_G1zCVJRQjp67ODfsSqiZWOZ9o=@protonmail.com/T/#u
> 
> The changes are removal of various `-fcall-used-*` flags, and changing
> `-mv8plus` to `-mcpu=v9`:
> 
> - `-fcall-used-*` flags should be safe to remove; the compiler will
>   stop using the registers specified as temporaries, but it is a safe
>   change wrt. the ABI. Assembly code can still use those registers
>   as needed.
>   It does bring a theoretical possible slowdown due to the compiler
>   having less registers to work with, but in practice - in my case,
>   at least - it seems to not make any difference with daily usage.
> 
> - More trivial is to change `-mv8plus` -> `-mcpu=v9`.
>   This should be safe too since the kernel seems to require a V9
>   processor to run anyway, so I'm changing the flag to one that is
>   portable between GCC and clang.
> 
> Also, as stated in the thread, building with these changes still result
> in a working kernel, at least for Sun T5120 and qemu virtual machines.
> 
> On the LLVM side, the effort for building Linux/SPARC is tracked here:
> https://github.com/llvm/llvm-project/issues/40792

This is really awesome to see, thanks for sending this patch!

I think a good amount of the reasoning below the '---' could probably
make it into the commit message as well but I don't have much of a
vision there, maybe one of the SPARC folks will.

I saw through the LLVM issue above that one other patch is necessary to
fix an issue in the vDSO [1], which I applied in testing this one. I
noticed in applying that change that you appear to be working on 6.1,
which is fine for now, but you'll need another diff once you get to a
newer version, as we stopped using CROSS_COMPILE to set clang's
'--target=' value:

diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
index 6c23c6af797f..2435efae67f5 100644
--- a/scripts/Makefile.clang
+++ b/scripts/Makefile.clang
@@ -10,6 +10,7 @@ CLANG_TARGET_FLAGS_mips		:= mipsel-linux-gnu
 CLANG_TARGET_FLAGS_powerpc	:= powerpc64le-linux-gnu
 CLANG_TARGET_FLAGS_riscv	:= riscv64-linux-gnu
 CLANG_TARGET_FLAGS_s390		:= s390x-linux-gnu
+CLANG_TARGET_FLAGS_sparc	:= sparc64-linux-gnu
 CLANG_TARGET_FLAGS_x86		:= x86_64-linux-gnu
 CLANG_TARGET_FLAGS_um		:= $(CLANG_TARGET_FLAGS_$(SUBARCH))
 CLANG_TARGET_FLAGS		:= $(CLANG_TARGET_FLAGS_$(SRCARCH))

With those, I can successfully build a kernel with clang that boots in
QEMU :)

  $ make -skj"$(nproc)" \
         ARCH=sparc64 \
         CC=clang \
         CROSS_COMPILE=sparc64-linux-gnu- \
         LLVM_IAS=0 \
         mrproper defconfig all

  $ qemu-system-sparc64 \
        -serial mon:stdio \
        -display none \
        -no-reboot \
        -M sun4u \
        -cpu 'TI UltraSparc IIi' \
        -m 512 \
        -append console=ttyS0 \
        -initrd sparc64-rootfs.cpio \
        -kernel arch/sparc/boot/image
  ...
  [    1.788544] Run /init as init process
  ...
  Linux version 6.10.0-rc4+ (nathan@thelio-3990X) (ClangBuiltLinux clang version 19.0.0git (https://github.com/llvm/llvm-project a083e50f53f0f9eb9ad0c5b65f3c627cf97043e6), GNU ld (GNU Binutils) 2.42) #1 SMP Fri Jun 21 11:36:18 MST 2024
  ...

Consider this:

Tested-by: Nathan Chancellor <nathan@kernel.org>

[1]: https://github.com/koachan/linux-clang/commit/c0114bfc7a4f64bc4d3e63eca6582ec827a8e2a2

> ---
>  arch/sparc/Makefile      | 4 ++--
>  arch/sparc/vdso/Makefile | 4 ++--
>  2 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
> index 757451c3ea1d..7318a8b452c3 100644
> --- a/arch/sparc/Makefile
> +++ b/arch/sparc/Makefile
> @@ -29,7 +29,7 @@ UTS_MACHINE    := sparc
>  # versions of gcc.  Some gcc versions won't pass -Av8 to binutils when you
>  # give -mcpu=v8.  This silently worked with older bintutils versions but
>  # does not any more.
> -KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7
> +KBUILD_CFLAGS  += -m32 -mcpu=v8 -pipe -mno-fpu
>  KBUILD_CFLAGS  += -Wa,-Av8
>  
>  KBUILD_AFLAGS  += -m32 -Wa,-Av8
> @@ -45,7 +45,7 @@ export BITS   := 64
>  UTS_MACHINE   := sparc64
>  
>  KBUILD_CFLAGS += -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow
> -KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare
> +KBUILD_CFLAGS += -ffixed-g4 -ffixed-g5 -Wno-sign-compare
>  KBUILD_CFLAGS += -Wa,--undeclared-regs
>  KBUILD_CFLAGS += $(call cc-option,-mtune=ultrasparc3)
>  KBUILD_AFLAGS += -m64 -mcpu=ultrasparc -Wa,--undeclared-regs
> diff --git a/arch/sparc/vdso/Makefile b/arch/sparc/vdso/Makefile
> index 243dbfc4609d..929140facabf 100644
> --- a/arch/sparc/vdso/Makefile
> +++ b/arch/sparc/vdso/Makefile
> @@ -46,7 +46,7 @@ CFL := $(PROFILING) -mcmodel=medlow -fPIC -O2 -fasynchronous-unwind-tables -m64
>         -fno-omit-frame-pointer -foptimize-sibling-calls \
>         -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
>  
> -SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5 -fcall-used-g5 -fcall-used-g7
> +SPARC_REG_CFLAGS = -ffixed-g4 -ffixed-g5
>  
>  $(vobjs): KBUILD_CFLAGS := $(filter-out $(RANDSTRUCT_CFLAGS) $(GCC_PLUGINS_CFLAGS) $(SPARC_REG_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
>  
> @@ -86,7 +86,7 @@ KBUILD_CFLAGS_32 += -fno-stack-protector
>  KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
>  KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
>  KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
> -KBUILD_CFLAGS_32 += -mv8plus
> +KBUILD_CFLAGS_32 += -mcpu=v9
>  $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
>  
>  $(obj)/vdso32.so.dbg: FORCE \
> 
> ---
> base-commit: 92e5605a199efbaee59fb19e15d6cc2103a04ec2
> change-id: 20240620-sparc-cflags-e7f2dbbd4b9d
> 
> Best regards,
> -- 
> Koakuma <koachan@protonmail.com>
> 
> 

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[John Paul Adrian Glaubitz]

Hi Nathan,

On Fri, 2024-06-21 at 11:53 -0700, Nathan Chancellor wrote:
> I think a good amount of the reasoning below the '---' could probably
> make it into the commit message as well but I don't have much of a
> vision there, maybe one of the SPARC folks will.
> 
> I saw through the LLVM issue above that one other patch is necessary to
> fix an issue in the vDSO [1], which I applied in testing this one. I
> noticed in applying that change that you appear to be working on 6.1,
> which is fine for now, but you'll need another diff once you get to a
> newer version, as we stopped using CROSS_COMPILE to set clang's
> '--target=' value:
> 
> diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
> index 6c23c6af797f..2435efae67f5 100644
> --- a/scripts/Makefile.clang
> +++ b/scripts/Makefile.clang
> @@ -10,6 +10,7 @@ CLANG_TARGET_FLAGS_mips		:= mipsel-linux-gnu
>  CLANG_TARGET_FLAGS_powerpc	:= powerpc64le-linux-gnu
>  CLANG_TARGET_FLAGS_riscv	:= riscv64-linux-gnu
>  CLANG_TARGET_FLAGS_s390		:= s390x-linux-gnu
> +CLANG_TARGET_FLAGS_sparc	:= sparc64-linux-gnu
>  CLANG_TARGET_FLAGS_x86		:= x86_64-linux-gnu
>  CLANG_TARGET_FLAGS_um		:= $(CLANG_TARGET_FLAGS_$(SUBARCH))
>  CLANG_TARGET_FLAGS		:= $(CLANG_TARGET_FLAGS_$(SRCARCH))
> 
> With those, I can successfully build a kernel with clang that boots in
> QEMU :)
> 
>   $ make -skj"$(nproc)" \
>          ARCH=sparc64 \
>          CC=clang \
>          CROSS_COMPILE=sparc64-linux-gnu- \
>          LLVM_IAS=0 \
>          mrproper defconfig all
> 
>   $ qemu-system-sparc64 \
>         -serial mon:stdio \
>         -display none \
>         -no-reboot \
>         -M sun4u \
>         -cpu 'TI UltraSparc IIi' \
>         -m 512 \
>         -append console=ttyS0 \
>         -initrd sparc64-rootfs.cpio \
>         -kernel arch/sparc/boot/image
>   ...
>   [    1.788544] Run /init as init process
>   ...
>   Linux version 6.10.0-rc4+ (nathan@thelio-3990X) (ClangBuiltLinux clang version 19.0.0git (https://github.com/llvm/llvm-project a083e50f53f0f9eb9ad0c5b65f3c627cf97043e6), GNU ld (GNU Binutils) 2.42) #1 SMP Fri Jun 21 11:36:18 MST 2024
>   ...

Wow, this is really great progress. Kudos to everyone who helped to make this happen!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[Koakuma]

Hi Nathan,

Nathan Chancellor <nathan@kernel.org> wrote:

> I saw through the LLVM issue above that one other patch is necessary to
> fix an issue in the vDSO [1], which I applied in testing this one. 

Mhmm, I did not submit that yet because I don't feel fully confident
with it. I think it should probably live in include/vdso/math64.h
as plain C code instead of the current asm version, but I don't know
what is the proper way to check the current environment's word size.
Is checking BITS_PER_LONG enough, or should I do it in another way?

> I noticed in applying that change that you appear to be working on 6.1,
> which is fine for now, but you'll need another diff once you get to a
> newer version, as we stopped using CROSS_COMPILE to set clang's
> '--target=' value:
> 
> diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
> index 6c23c6af797f..2435efae67f5 100644
> --- a/scripts/Makefile.clang
> +++ b/scripts/Makefile.clang
> @@ -10,6 +10,7 @@ CLANG_TARGET_FLAGS_mips := mipsel-linux-gnu
> CLANG_TARGET_FLAGS_powerpc := powerpc64le-linux-gnu
> CLANG_TARGET_FLAGS_riscv := riscv64-linux-gnu
> CLANG_TARGET_FLAGS_s390 := s390x-linux-gnu
> +CLANG_TARGET_FLAGS_sparc := sparc64-linux-gnu
> CLANG_TARGET_FLAGS_x86 := x86_64-linux-gnu
> CLANG_TARGET_FLAGS_um := $(CLANG_TARGET_FLAGS_$(SUBARCH))
> CLANG_TARGET_FLAGS := $(CLANG_TARGET_FLAGS_$(SRCARCH))

Yeah, I was working with 6.1 at that time since it's the version
that my distro have installed for me. Now this is more of a workflow
question, but this means I should submit a v2 with this change
merged in with mine too, right?

And thanks for the feedback!

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[Nathan Chancellor]

Hi Koakuma,

On Sat, Jun 22, 2024 at 12:18:17PM +0000, Koakuma wrote:
> Nathan Chancellor <nathan@kernel.org> wrote:
> 
> > I saw through the LLVM issue above that one other patch is necessary to
> > fix an issue in the vDSO [1], which I applied in testing this one. 
> 
> Mhmm, I did not submit that yet because I don't feel fully confident
> with it. I think it should probably live in include/vdso/math64.h
> as plain C code instead of the current asm version, but I don't know
> what is the proper way to check the current environment's word size.
> Is checking BITS_PER_LONG enough, or should I do it in another way?

Yes, I believe that is what BITS_PER_LONG is there for, you will see
other checks in the tree for that. You could also reach out to the
maintainers of the generic vDSO infrastructure to see if they have any
ideas or suggestions for integration.

> > I noticed in applying that change that you appear to be working on 6.1,
> > which is fine for now, but you'll need another diff once you get to a
> > newer version, as we stopped using CROSS_COMPILE to set clang's
> > '--target=' value:
> > 
> > diff --git a/scripts/Makefile.clang b/scripts/Makefile.clang
> > index 6c23c6af797f..2435efae67f5 100644
> > --- a/scripts/Makefile.clang
> > +++ b/scripts/Makefile.clang
> > @@ -10,6 +10,7 @@ CLANG_TARGET_FLAGS_mips := mipsel-linux-gnu
> > CLANG_TARGET_FLAGS_powerpc := powerpc64le-linux-gnu
> > CLANG_TARGET_FLAGS_riscv := riscv64-linux-gnu
> > CLANG_TARGET_FLAGS_s390 := s390x-linux-gnu
> > +CLANG_TARGET_FLAGS_sparc := sparc64-linux-gnu
> > CLANG_TARGET_FLAGS_x86 := x86_64-linux-gnu
> > CLANG_TARGET_FLAGS_um := $(CLANG_TARGET_FLAGS_$(SUBARCH))
> > CLANG_TARGET_FLAGS := $(CLANG_TARGET_FLAGS_$(SRCARCH))
> 
> Yeah, I was working with 6.1 at that time since it's the version
> that my distro have installed for me. Now this is more of a workflow

That makes sense. I do think you should start working off of a more
recent version (ideally at least mainline) for your future revisions,
just so that your patches can be applied with less friction on
maintainers. That can help your patches get picked up quicker :)

> question, but this means I should submit a v2 with this change
> merged in with mine too, right?

Here is what I would do:

1. Either keep this patch the way that it is or break it up into two
   separate patches (especially given Adrian's other review comment):

   One for removing the '-fcall-used' flags, with the comments about how
   it does not impact the ABI and the registers can still be used in
   assembly if needed, perhaps with some benchmarks with any codegen?
   Might not be strictly necessary since Sam did not seem opposed in the
   previous discussion.

   One for changing the vDSO from '-mv8plus' to '-mcpu=v9' (if this is
   still okay).

2. Add another patch with that diff above with some notes about what was
   tested to justify allowing this now.

You'll end up with either a two or three patch series. I would send this
series to both the SPARC people that you have added here along with the
Kbuild and ClangBuiltLinux folks, which you can get from the output of

  $ scripts/get_maintainers.pl scripts/Makefile.clang

or use 'b4 prep --auto-to-cc' after crafting the series, since it
appears you used it for this series. For the cover letter, you can add
some commentary about what was tested and request integration from
either the SPARC folks or Masahiro, depending on who wants to carry the
changes, since they should go through one tree atomically ideally.

If you have any questions about or issues with that comment or any other
aspect of this process, I am happy to answer or clarify as necessary!
I am in the #clang-built-linux channel in the LLVM Discord and
#clangbuiltlinux on Libera if anything comes up.

> And thanks for the feedback!

Always happy to help get more people involved with the kernel,
especially from the clang/LLVM side :)

Cheers,
Nathan

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[John Paul Adrian Glaubitz]

Hi Koakuma,

On Thu, 2024-06-20 at 22:56 +0700, Koakuma via B4 Relay wrote:
> - More trivial is to change `-mv8plus` -> `-mcpu=v9`.
>   This should be safe too since the kernel seems to require a V9
>   processor to run anyway, so I'm changing the flag to one that is
>   portable between GCC and clang.

I just looked up what the exact difference between V8plus and 32-bit
V9 is and it turns out it's not exactly the same [1].

V8plus does not use VIS instructions and also has a different ELF machine
type, namely EM_SPARC32PLUS instead of EM_SPARCV9 if I understand correctly.

So, we should make sure that the above change will not affect the ELF machine
type.

Adrian

> [1] https://stackoverflow.com/questions/23506538/what-is-em-sparc32plus-for

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[Koakuma]

Hi Adrian~

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> V8plus does not use VIS instructions and also has a different ELF machine
> type, namely EM_SPARC32PLUS instead of EM_SPARCV9 if I understand correctly.
>
> So, we should make sure that the above change will not affect the ELF machine
> type.

When assembling with GNU as, there seem to be no control as to what
machine type we want to emit, as it simply tries to autodetect it based
on the instruction mix in the assembly code:
- If there's a V9 instruction inside, then use EM_SPARC32PLUS; and
- Emit EM_SPARC otherwise.

This is also the case with GCC - it simply happens that GCC will try
to emit V9 instructions whenever possible with `-m32 -mv8plus`
or `-m32 -mcpu=v9` so there's a high chance that the resulting object
file will be of a EM_SPARC32PLUS type, but this does not seem to be
a guaranteed behavior.

With LLVM's as, we can have finer control of emitted machine type, but
so far it never sets the type to EM_SPARC32PLUS - for this I have made
a patch over at https://github.com/llvm/llvm-project/pull/96583.

As for VIS, GCC (and clang when it eventually supports vectorization)
should not emit it unless explicitly asked, so I think we are
in the clear here?

> With `-mvis`, GCC generates code that takes advantage of
> the UltraSPARC Visual Instruction Set extensions.
> The default is `-mno-vis`.

From https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#index-mvis

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[John Paul Adrian Glaubitz]

Hi Koakuma,

thanks for doing the research work!

On Tue, 2024-06-25 at 02:06 +0000, Koakuma wrote:
> John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> > V8plus does not use VIS instructions and also has a different ELF machine
> > type, namely EM_SPARC32PLUS instead of EM_SPARCV9 if I understand correctly.
> > 
> > So, we should make sure that the above change will not affect the ELF machine
> > type.
> 
> When assembling with GNU as, there seem to be no control as to what
> machine type we want to emit, as it simply tries to autodetect it based
> on the instruction mix in the assembly code:
> - If there's a V9 instruction inside, then use EM_SPARC32PLUS; and
> - Emit EM_SPARC otherwise.

Interesting. I actually expected some flags being passed to the linker to
enable the EM_SPARC32PLUS machine type.

> This is also the case with GCC - it simply happens that GCC will try
> to emit V9 instructions whenever possible with `-m32 -mv8plus`
> or `-m32 -mcpu=v9` so there's a high chance that the resulting object
> file will be of a EM_SPARC32PLUS type, but this does not seem to be
> a guaranteed behavior.

Would be interesting to find out what Sun's own C/C++ compiler (Sun Studio)
does in this case. I can try to run some tests on Solaris or you can check
out the Solaris machines in the GCC compile farm [1].

> With LLVM's as, we can have finer control of emitted machine type, but
> so far it never sets the type to EM_SPARC32PLUS - for this I have made
> a patch over at https://github.com/llvm/llvm-project/pull/96583.

I just had a brief look - will do the proper review later - and I think
it's the right approach for the time being. However, I am wondering whether
we should add "-mv8plus" to clang as well.

I wondering though whether "-mcpu=v9 -m32" is truly identical to "-mv8plus"
or not.

> As for VIS, GCC (and clang when it eventually supports vectorization)
> should not emit it unless explicitly asked, so I think we are
> in the clear here?
> 
> > With `-mvis`, GCC generates code that takes advantage of
> > the UltraSPARC Visual Instruction Set extensions.
> > The default is `-mno-vis`.
> 
> From https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#index-mvis

OK, very good to know. Yes, I think we should be safe here.

Again, thanks a lot for getting this sorted out so quickly!

Adrian

> [1] https://gcc.gnu.org/wiki/CompileFarm

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible

[Koakuma]

Hi Adrian~

John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> Would be interesting to find out what Sun's own C/C++ compiler (Sun Studio)
> does in this case. I can try to run some tests on Solaris or you can check
> out the Solaris machines in the GCC compile farm [1].

I am using the version included in Oracle Studio 12.6, and it seems
that it always emit a EM_SPARC32PLUS type for 32-bit objects.

The documentation for the -xarch also states that even when using
the most generic target (`sparc`), it only supports emitting for V9 ISA
(that is, EM_SPARC32PLUS for 32-bit target):

> sparc
> Compile for the SPARC-V9 ISA.
> Compile for the V9 ISA, but without the Visual Instruction Set (VIS),
> and without other implementation-specific ISA extensions. This option
> enables the compiler to generate code for good performance on
> the V9 ISA.

From https://docs.oracle.com/cd/E77782_01/html/E77803/cc-1.html

Other versions of the compiler might act differently, but sadly I have
no access to them.

> I just had a brief look - will do the proper review later - and I think
> it's the right approach for the time being. However, I am wondering whether
> we should add "-mv8plus" to clang as well.
> 
> I wondering though whether "-mcpu=v9 -m32" is truly identical to "-mv8plus"
> or not.

Hmm, so I just found out after some digging that while `-m32 -mv8plus`
and `-m32 -mcpu=v9` can differ a little, I am not sure if supporting
the full behavior in clang would be worth the effort? I think I can
add `-mv8plus`/`-mno-v8plus` as an alias for `-mcpu=v9`/`-mcpu=v8`, but
any more would probably be too much effort for too little gain?

`-mv8plus` basically allows the compiler to treat the G and O registers
as being 64-bit wide, allowing the compiler to use any of the new
64-bit V9 instructions (e.g. `casx`) as it sees fit. From GCC's docs:

> With `-mv8plus`, GCC generates code for the SPARC-V8+ ABI.
> The difference from the V8 ABI is that the global and out registers
> are considered 64 bits wide. 

https://gcc.gnu.org/onlinedocs/gcc/SPARC-Options.html#index-mv8plus

Note that it does not change value passing in parameters or returns
(outgoing parameters still need to be trimmed to 32-bit even though
they are placed in the O registers, for example) so EM_SPARC32PLUS
objects can be freely mixed with EM_SPARC ones.

Also, this seems to be undocumented, but at least from my testing,
`-mv8plus` implies `-mcpu=v9` unless it gets overridden by a later
`-mcpu` flag. So, in theory, it is totally permissible to have
flags like `-m32 -mno-v8plus -mcpu=v9` or `-m32 -mv8plus -mcpu=v8`,
however this will be useless in practice since the combination will
end up disallowing the compiler from using any V9 instructions...

And so far, looking around at kernel sources at least, there seem
to be no need for such kind of flag combinations... though probably
you or others who are more familar could comment on this?