Re: [PATCH v2 0/4] riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 3486 bytes --]

On Sun, Jun 25, 2023 at 08:24:56PM +0800, Jisheng Zhang wrote:
> On Fri, Jun 23, 2023 at 10:17:54AM -0700, Nick Desaulniers wrote:
> > On Thu, Jun 22, 2023 at 11:18:03PM +0000, Nathan Chancellor wrote:
> > > If you wanted to restrict it to just LD_IS_BFD in arch/riscv/Kconfig,
> > > that would be fine with me too.
> > > 
> > >   select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if LD_IS_BFD
> > 
> > Hi Jisheng, would you mind sending a v3 with the attached patch applied
> > on top / at the end of your series?
> 
> Hi Nick, Nathan, Palmer,
> 
> I saw the series has been applied to riscv-next, so I'm not sure which
> solution would it be, Palmer to apply Nick's patch to riscv-next or
> I to send out v3, any suggestion is appreciated.

I don't see what you are seeing w/ riscv/for-next. HEAD is currently at
4681dacadeef ("riscv: replace deprecated scall with ecall") and there
are no patches from your series in the branch:
https://git.kernel.org/pub/scm/linux/kernel/git/riscv/linux.git/log/?h=for-next

Cheers,
Conor.

> > > Nick said he would work on a report for the LLVM side, so as long as
> > > this issue is handled in some way to avoid regressing LLD builds until
> > > it is resolved, I don't think there is anything else for the kernel to
> > > do. We like to have breadcrumbs via issue links, not sure if the report
> > > will be internal to Google or on LLVM's issue tracker though;
> > > regardless, we will have to touch this block to add a version check
> > > later, at which point we can add a link to the fix in LLD.
> > 
> > https://github.com/ClangBuiltLinux/linux/issues/1881
> 
> > From 3e5e010958ee41b9fb408cfade8fb017c2fe7169 Mon Sep 17 00:00:00 2001
> > From: Nick Desaulniers <ndesaulniers@google.com>
> > Date: Fri, 23 Jun 2023 10:06:17 -0700
> > Subject: [PATCH] riscv: disable HAVE_LD_DEAD_CODE_DATA_ELIMINATION for LLD
> > 
> > Linking allyesconfig with ld.lld-17 with CONFIG_DEAD_CODE_ELIMINATION=y
> > takes hours.  Assuming this is a performance regression that can be
> > fixed, tentatively disable this for now so that allyesconfig builds
> > don't start timing out.  If and when there's a fix to ld.lld, this can
> > be converted to a version check instead so that users of older but still
> > supported versions of ld.lld don't hurt themselves by enabling
> > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y.
> > 
> > Link: https://github.com/ClangBuiltLinux/linux/issues/1881
> > Reported-by: Palmer Dabbelt <palmer@dabbelt.com>
> > Suggested-by: Nathan Chancellor <nathan@kernel.org>
> > Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
> > ---
> > Hi Jisheng, would you mind sending a v3 with this patch on top/at the
> > end of your patch series?
> > 
> >  arch/riscv/Kconfig | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> > index 8effe5bb7788..0573991e9b78 100644
> > --- a/arch/riscv/Kconfig
> > +++ b/arch/riscv/Kconfig
> > @@ -116,7 +116,8 @@ config RISCV
> >  	select HAVE_KPROBES if !XIP_KERNEL
> >  	select HAVE_KPROBES_ON_FTRACE if !XIP_KERNEL
> >  	select HAVE_KRETPROBES if !XIP_KERNEL
> > -	select HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> > +	# https://github.com/ClangBuiltLinux/linux/issues/1881
> > +	select HAVE_LD_DEAD_CODE_DATA_ELIMINATION if !LD_IS_LLD
> >  	select HAVE_MOVE_PMD
> >  	select HAVE_MOVE_PUD
> >  	select HAVE_PCI
> > -- 
> > 2.41.0.162.gfafddb0af9-goog
> > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]