From: Nathan Chancellor <nathan@kernel.org>
To: Koakuma <koachan@protonmail.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
glaubitz@physik.fu-berlin.de, sparclinux@vger.kernel.org,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] sparc/build: Make all compiler flags also clang-compatible
Date: Mon, 24 Jun 2024 13:14:47 -0700 [thread overview]
Message-ID: <20240624201447.GA774138@thelio-3990X> (raw)
In-Reply-To: <e26PTXUXEz8OYXmaeKn4Mpuejr4IOlFfFwdB5vpsluXlYiqDdlyQTYcDtdAny_o4gO4SfPeQCCN2qpyT6e0nog5EaP3xk2SeUPTrF54p1gM=@protonmail.com>
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
next prev parent reply other threads:[~2024-06-24 20:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-20 15:56 Koakuma via B4 Relay
2024-06-21 18:53 ` Nathan Chancellor
2024-06-22 7:29 ` John Paul Adrian Glaubitz
2024-06-22 12:18 ` Koakuma
2024-06-24 20:14 ` Nathan Chancellor [this message]
2024-06-23 16:53 ` John Paul Adrian Glaubitz
2024-06-25 2:06 ` Koakuma
2024-06-25 7:20 ` John Paul Adrian Glaubitz
2024-06-25 16:37 ` Koakuma
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20240624201447.GA774138@thelio-3990X \
--to=nathan@kernel.org \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=glaubitz@physik.fu-berlin.de \
--cc=justinstitt@google.com \
--cc=koachan@protonmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=morbo@google.com \
--cc=ndesaulniers@google.com \
--cc=sparclinux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®