Building the Linux kernel with Clang and LLVM
 help / color / mirror / Atom feed
From: Nathan Chancellor <nathan@kernel.org>
To: Tiezhu Yang <yangtiezhu@loongson.cn>
Cc: Huacai Chen <chenhuacai@kernel.org>,
	Miguel Ojeda <ojeda@kernel.org>, WANG Rui <wangrui@loongson.cn>,
	rust-for-linux@vger.kernel.org, loongarch@lists.linux.dev,
	linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH v1 1/2] LoongArch: Make LTO case independent in Makefile
Date: Mon, 22 Sep 2025 18:10:57 -0700	[thread overview]
Message-ID: <20250923011057.GA3980504@ax162> (raw)
In-Reply-To: <750c907d-cc95-5116-4507-52dd48927cec@loongson.cn>

> > > ifdef CONFIG_LTO_CLANG
> > > ifdef CONFIG_LLD_HAS_ANNOTATE_TABLEJUMP
> > > KBUILD_LDFLAGS                  += -mllvm --loongarch-annotate-tablejump
> > > else
> > > KBUILD_LDFLAGS                  += -mllvm --no-jump-tables
> > > endif

There is no '--no-jump-tables' LLVM option so this will not work.
Shouldn't -fno-jump-tables and -Zno-jump-tables take care of generating
jump tables?

> I do not know whether this is valid, you can test it with llvm 18
> and llvm 20 if you think it is a proper way.

For what it's worth, Huacai's original suggestion of

    KBUILD_LDFLAGS += $(call ld-option,-mllvm --loongarch-annotate-tablejump)

appears to work for me and I do not see any objtool warnings with LTO
enabled but I might be missing something.

> But IIRC, there is objtool warning with llvm 18, I reported to llvm
> developer Wang Lei and he fixed it as the following commit:
> 
> [LoongArch] Avoid indirect branch jumps using the ra register
> https://github.com/llvm/llvm-project/commit/21ef17c62645
> 
> Actually, the above commit solved a performance issue of llvm compiler,
> so I prefer to update the minimal llvm version to 20 for LoongArch.

I tend to let architecture maintainers make the call around minimum
supported versions of compilers, so if that is how you would like to
proceed, I am fine with that. I will say LLVM 20 is pretty new (released
on March 4th, 2025) but I expect most of your users to probably be using
bleeding edge tools for all the changes you make in the compiler and
lower level libraries?

Cheers,
Nathan

  reply	other threads:[~2025-09-23  1:11 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20250909092707.3127-1-yangtiezhu@loongson.cn>
     [not found] ` <20250909092707.3127-2-yangtiezhu@loongson.cn>
2025-09-20  6:15   ` [PATCH v1 1/2] LoongArch: Make LTO case independent in Makefile Nathan Chancellor
2025-09-20  8:23     ` Huacai Chen
2025-09-20  9:19       ` Tiezhu Yang
2025-09-20 10:22         ` Tiezhu Yang
2025-09-20 11:41           ` Huacai Chen
2025-09-20 12:52             ` Tiezhu Yang
2025-09-23  1:10               ` Nathan Chancellor [this message]
2025-09-23  3:13                 ` Tiezhu Yang

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=20250923011057.GA3980504@ax162 \
    --to=nathan@kernel.org \
    --cc=chenhuacai@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=loongarch@lists.linux.dev \
    --cc=ojeda@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=wangrui@loongson.cn \
    --cc=yangtiezhu@loongson.cn \
    /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