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

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

[Palmer Dabbelt]

On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
>>
>> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
>>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
>>> > When trying to run linux with various opensource riscv core on
>>> > resource limited FPGA platforms, for example, those FPGAs with less
>>> > than 16MB SDRAM, I want to save mem as much as possible. One of the
>>> > major technologies is kernel size optimizations, I found that riscv
>>> > does not currently support HAVE_LD_DEAD_CODE_DATA_ELIMINATION, which
>>> > passes -fdata-sections, -ffunction-sections to CFLAGS and passes the
>>> > --gc-sections flag to the linker.
>>> >
>>> > This not only benefits my case on FPGA but also benefits defconfigs.
>>> > Here are some notable improvements from enabling this with defconfigs:
>>> >
>>> > nommu_k210_defconfig:
>>> >    text    data     bss     dec     hex
>>> > 1112009  410288   59837 1582134  182436     before
>>> >  962838  376656   51285 1390779  1538bb     after
>>> >
>>> > rv32_defconfig:
>>> >    text    data     bss     dec     hex
>>> > 8804455 2816544  290577 11911576 b5c198     before
>>> > 8692295 2779872  288977 11761144 b375f8     after
>>> >
>>> > defconfig:
>>> >    text    data     bss     dec     hex
>>> > 9438267 3391332  485333 13314932 cb2b74     before
>>> > 9285914 3350052  483349 13119315 c82f53     after
>>> >
>>> > patch1 and patch2 are clean ups.
>>> > patch3 fixes a typo.
>>> > patch4 finally enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION for riscv.
>>> >
>>> > NOTE: Zhangjin Wu firstly sent out a patch to enable dead code
>>> > elimination for riscv several months ago, I didn't notice it until
>>> > yesterday. Although it missed some preparations and some sections's
>>> > keeping, he is the first person to enable this feature for riscv. To
>>> > ease merging, this series take his patch into my entire series and
>>> > makes patch4 authored by him after getting his ack to reflect
>>> > the above fact.
>>> >
>>> > Since v1:
>>> >   - collect Reviewed-by, Tested-by tag
>>> >   - Make patch4 authored by Zhangjin Wu, add my co-developed-by tag
>>> >
>>> > Jisheng Zhang (3):
>>> >   riscv: move options to keep entries sorted
>>> >   riscv: vmlinux-xip.lds.S: remove .alternative section
>>> >   vmlinux.lds.h: use correct .init.data.* section name
>>> >
>>> > Zhangjin Wu (1):
>>> >   riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
>>> >
>>> >  arch/riscv/Kconfig                  |  13 +-
>>> >  arch/riscv/kernel/vmlinux-xip.lds.S |   6 -
>>> >  arch/riscv/kernel/vmlinux.lds.S     |   6 +-
>>> >  include/asm-generic/vmlinux.lds.h   |   2 +-
>>> >  4 files changed, 11 insertions(+), 16 deletions(-)
>>>
>>> Do you have a base commit for this?  It's not applying to 6.4-rc1 and the
>>> patchwork bot couldn't find one either.
>>
>> Hi Palmer,
>>
>> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
>> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
>> series is based on 6.4-rc2.
>
> Thanks.

Sorry to be so slow here, but I think this is causing LLD to hang on 
allmodconfig.  I'm still getting to the bottom of it, there's a few 
other things I have in flight still.

>
>>
>> Thanks

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

[Nick Desaulniers]

On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
> >>
> >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
> >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
> >>> > When trying to run linux with various opensource riscv core on
> >>> > resource limited FPGA platforms, for example, those FPGAs with less
> >>> > than 16MB SDRAM, I want to save mem as much as possible. One of the
> >>> > major technologies is kernel size optimizations, I found that riscv
> >>> > does not currently support HAVE_LD_DEAD_CODE_DATA_ELIMINATION, which
> >>> > passes -fdata-sections, -ffunction-sections to CFLAGS and passes the
> >>> > --gc-sections flag to the linker.
> >>> >
> >>> > This not only benefits my case on FPGA but also benefits defconfigs.
> >>> > Here are some notable improvements from enabling this with defconfigs:
> >>> >
> >>> > nommu_k210_defconfig:
> >>> >    text    data     bss     dec     hex
> >>> > 1112009  410288   59837 1582134  182436     before
> >>> >  962838  376656   51285 1390779  1538bb     after
> >>> >
> >>> > rv32_defconfig:
> >>> >    text    data     bss     dec     hex
> >>> > 8804455 2816544  290577 11911576 b5c198     before
> >>> > 8692295 2779872  288977 11761144 b375f8     after
> >>> >
> >>> > defconfig:
> >>> >    text    data     bss     dec     hex
> >>> > 9438267 3391332  485333 13314932 cb2b74     before
> >>> > 9285914 3350052  483349 13119315 c82f53     after
> >>> >
> >>> > patch1 and patch2 are clean ups.
> >>> > patch3 fixes a typo.
> >>> > patch4 finally enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION for riscv.
> >>> >
> >>> > NOTE: Zhangjin Wu firstly sent out a patch to enable dead code
> >>> > elimination for riscv several months ago, I didn't notice it until
> >>> > yesterday. Although it missed some preparations and some sections's
> >>> > keeping, he is the first person to enable this feature for riscv. To
> >>> > ease merging, this series take his patch into my entire series and
> >>> > makes patch4 authored by him after getting his ack to reflect
> >>> > the above fact.
> >>> >
> >>> > Since v1:
> >>> >   - collect Reviewed-by, Tested-by tag
> >>> >   - Make patch4 authored by Zhangjin Wu, add my co-developed-by tag
> >>> >
> >>> > Jisheng Zhang (3):
> >>> >   riscv: move options to keep entries sorted
> >>> >   riscv: vmlinux-xip.lds.S: remove .alternative section
> >>> >   vmlinux.lds.h: use correct .init.data.* section name
> >>> >
> >>> > Zhangjin Wu (1):
> >>> >   riscv: enable HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> >>> >
> >>> >  arch/riscv/Kconfig                  |  13 +-
> >>> >  arch/riscv/kernel/vmlinux-xip.lds.S |   6 -
> >>> >  arch/riscv/kernel/vmlinux.lds.S     |   6 +-
> >>> >  include/asm-generic/vmlinux.lds.h   |   2 +-
> >>> >  4 files changed, 11 insertions(+), 16 deletions(-)
> >>>
> >>> Do you have a base commit for this?  It's not applying to 6.4-rc1 and the
> >>> patchwork bot couldn't find one either.
> >>
> >> Hi Palmer,
> >>
> >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
> >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
> >> series is based on 6.4-rc2.
> >
> > Thanks.
>
> Sorry to be so slow here, but I think this is causing LLD to hang on
> allmodconfig.  I'm still getting to the bottom of it, there's a few
> other things I have in flight still.

Confirmed with v3 on mainline (linux-next is pretty red at the moment).
https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/

I was able to dump a backtrace of all of LLD's threads and all threads
seemed parked in a futex wait except for one thread with a more
interesting trace.

0x0000555557ea01ce in
lld::elf::LinkerScript::addOrphanSections()::$_0::operator()(lld::elf::InputSectionBase*)
const ()
(gdb) bt
#0  0x0000555557ea01ce in
lld::elf::LinkerScript::addOrphanSections()::$_0::operator()(lld::elf::InputSectionBase*)
const ()
#1  0x0000555557e9fc3f in lld::elf::LinkerScript::addOrphanSections() ()
#2  0x0000555557dd0ca1 in
lld::elf::LinkerDriver::link(llvm::opt::InputArgList&) ()
#3  0x0000555557dc19a8 in
lld::elf::LinkerDriver::linkerMain(llvm::ArrayRef<char const*>) ()
#4  0x0000555557dbfff9 in lld::elf::link(llvm::ArrayRef<char const*>,
llvm::raw_ostream&, llvm::raw_ostream&, bool, bool) ()
#5  0x0000555557c3ffcf in lldMain(int, char const**,
llvm::raw_ostream&, llvm::raw_ostream&, bool) ()
#6  0x0000555557c3f7aa in lld_main(int, char**, llvm::ToolContext const&) ()
#7  0x0000555557c41ee1 in main ()

Makes me wonder if there's some kind of loop adding orphan sections
that aren't referenced, so they're cleaned up.

Though I don't think it's a hang; IIRC dead code elimination adds a
measurable amount of time to the build.  As code is unreferenced and
removed, I think the linker is reshuffling layout and thus recomputing
relocations.

Though triple checking mainline without this patch vs mainline with
this patch, twice now I just got an error from LLD (in 2 minutes on my
system):

ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(efi-stub-entry.stub.o):(.init.bss.screen_info_offset)
is being placed in '.init.bss.screen_info_offset'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.data.efi_nokaslr)
is being placed in '.init.data.efi_nokaslr'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.bss.efi_noinitrd)
is being placed in '.init.bss.efi_noinitrd'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.bss.efi_nochunk)
is being placed in '.init.bss.efi_nochunk'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.bss.efi_novamap)
is being placed in '.init.bss.efi_novamap'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(efi-stub-helper.stub.o):(.init.bss.efi_disable_pci_dma)
is being placed in '.init.bss.efi_disable_pci_dma'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(file.stub.o):(.init.bss.efi_open_device_path.text_to_dp)
is being placed in '.init.bss.efi_open_device_path.text_to_dp'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(gop.stub.o):(.init.bss.cmdline.0)
is being placed in '.init.bss.cmdline.0'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(gop.stub.o):(.init.bss.cmdline.1)
is being placed in '.init.bss.cmdline.1'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(gop.stub.o):(.init.bss.cmdline.2)
is being placed in '.init.bss.cmdline.2'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(gop.stub.o):(.init.bss.cmdline.3)
is being placed in '.init.bss.cmdline.3'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(gop.stub.o):(.init.bss.cmdline.4)
is being placed in '.init.bss.cmdline.4'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(printk.stub.o):(.init.data.efi_loglevel)
is being placed in '.init.data.efi_loglevel'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(riscv.stub.o):(.init.bss.hartid)
is being placed in '.init.bss.hartid'
ld.lld: error: ./drivers/firmware/efi/libstub/lib.a(systable.stub.o):(.init.bss.efi_system_table)
is being placed in '.init.bss.efi_system_table'

is it perhaps that these sections need placement in the linker script?
 This is from the orphan section warn linker command line flag.

Does the EFI stub have one linker script, or one per arch? (Or am I
mistaken and the EFI stub is part of vmlinux)?


>
> >
> >>
> >> Thanks
>


-- 
Thanks,
~Nick Desaulniers

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

[Conor Dooley]

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

On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
> On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
> > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
> > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:

> > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
> > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
> > >> series is based on 6.4-rc2.
> > >
> > > Thanks.
> >
> > Sorry to be so slow here, but I think this is causing LLD to hang on
> > allmodconfig.  I'm still getting to the bottom of it, there's a few
> > other things I have in flight still.
> 
> Confirmed with v3 on mainline (linux-next is pretty red at the moment).
> https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/

Just FYI Nick, there's been some concurrent work here from different
people working on the same thing & the v3 you linked (from Zhangjin) was
superseded by this v2 (from Jisheng).

Cheers,
Conor.

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

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

[Nick Desaulniers]

On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
>
> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
> > > >> series is based on 6.4-rc2.
> > > >
> > > > Thanks.
> > >
> > > Sorry to be so slow here, but I think this is causing LLD to hang on
> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
> > > other things I have in flight still.
> >
> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
>
> Just FYI Nick, there's been some concurrent work here from different
> people working on the same thing & the v3 you linked (from Zhangjin) was
> superseded by this v2 (from Jisheng).

Ah! I've been testing the deprecated patch set, sorry I just looked on
lore for "dead code" on riscv-linux and grabbed the first thread,
without noticing the difference in authors or new version numbers for
distinct series. ok, nevermind my noise.  I'll follow up with the
correct patch set, sorry!

>
> Cheers,
> Conor.



-- 
Thanks,
~Nick Desaulniers

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

[Palmer Dabbelt]

On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
> On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
>>
>> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
>> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
>> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
>> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
>> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
>>
>> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
>> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
>> > > >> series is based on 6.4-rc2.
>> > > >
>> > > > Thanks.
>> > >
>> > > Sorry to be so slow here, but I think this is causing LLD to hang on
>> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
>> > > other things I have in flight still.
>> >
>> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
>> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
>>
>> Just FYI Nick, there's been some concurrent work here from different
>> people working on the same thing & the v3 you linked (from Zhangjin) was
>> superseded by this v2 (from Jisheng).
>
> Ah! I've been testing the deprecated patch set, sorry I just looked on
> lore for "dead code" on riscv-linux and grabbed the first thread,
> without noticing the difference in authors or new version numbers for
> distinct series. ok, nevermind my noise.  I'll follow up with the
> correct patch set, sorry!

Ya, I hadn't even noticed the v3 because I pretty much only look at 
patchwork these days.  Like we talked about in IRC, I'm going to go test 
the merge of this one and see what's up -- I've got it staged at 
<https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>, 
though that won't be a stable hash if it's actually broken...

>
>>
>> Cheers,
>> Conor.
>
>
>
> -- 
> Thanks,
> ~Nick Desaulniers

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

[Nick Desaulniers]

On Tue, Jun 20, 2023 at 4:41 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
> > On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
> >>
> >> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
> >> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> >> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
> >> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
> >> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
> >>
> >> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
> >> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
> >> > > >> series is based on 6.4-rc2.
> >> > > >
> >> > > > Thanks.
> >> > >
> >> > > Sorry to be so slow here, but I think this is causing LLD to hang on
> >> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
> >> > > other things I have in flight still.
> >> >
> >> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
> >> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
> >>
> >> Just FYI Nick, there's been some concurrent work here from different
> >> people working on the same thing & the v3 you linked (from Zhangjin) was
> >> superseded by this v2 (from Jisheng).
> >
> > Ah! I've been testing the deprecated patch set, sorry I just looked on
> > lore for "dead code" on riscv-linux and grabbed the first thread,
> > without noticing the difference in authors or new version numbers for
> > distinct series. ok, nevermind my noise.  I'll follow up with the
> > correct patch set, sorry!
>
> Ya, I hadn't even noticed the v3 because I pretty much only look at
> patchwork these days.  Like we talked about in IRC, I'm going to go test
> the merge of this one and see what's up -- I've got it staged at
> <https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>,
> though that won't be a stable hash if it's actually broken...

Ok, https://lore.kernel.org/linux-riscv/20230523165502.2592-1-jszhang@kernel.org/
built for me.  If you're seeing a hang, please let me know what
version of LLD you're using and I'll build that tag from source to see
if I can reproduce, then bisect if so.

$ ARCH=riscv LLVM=1 /usr/bin/time -v make -j128 allmodconfig vmlinux
...
        Elapsed (wall clock) time (h:mm:ss or m:ss): 2:35.68
...

Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build

>
> >
> >>
> >> Cheers,
> >> Conor.
> >
> >
> >
> > --
> > Thanks,
> > ~Nick Desaulniers



-- 
Thanks,
~Nick Desaulniers

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

[Palmer Dabbelt]

On Tue, 20 Jun 2023 13:47:07 PDT (-0700), ndesaulniers@google.com wrote:
> On Tue, Jun 20, 2023 at 4:41 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
>> > On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
>> >>
>> >> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
>> >> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>> >> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
>> >> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
>> >> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
>> >> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
>> >>
>> >> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
>> >> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
>> >> > > >> series is based on 6.4-rc2.
>> >> > > >
>> >> > > > Thanks.
>> >> > >
>> >> > > Sorry to be so slow here, but I think this is causing LLD to hang on
>> >> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
>> >> > > other things I have in flight still.
>> >> >
>> >> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
>> >> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
>> >>
>> >> Just FYI Nick, there's been some concurrent work here from different
>> >> people working on the same thing & the v3 you linked (from Zhangjin) was
>> >> superseded by this v2 (from Jisheng).
>> >
>> > Ah! I've been testing the deprecated patch set, sorry I just looked on
>> > lore for "dead code" on riscv-linux and grabbed the first thread,
>> > without noticing the difference in authors or new version numbers for
>> > distinct series. ok, nevermind my noise.  I'll follow up with the
>> > correct patch set, sorry!
>>
>> Ya, I hadn't even noticed the v3 because I pretty much only look at
>> patchwork these days.  Like we talked about in IRC, I'm going to go test
>> the merge of this one and see what's up -- I've got it staged at
>> <https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>,
>> though that won't be a stable hash if it's actually broken...
>
> Ok, https://lore.kernel.org/linux-riscv/20230523165502.2592-1-jszhang@kernel.org/
> built for me.  If you're seeing a hang, please let me know what
> version of LLD you're using and I'll build that tag from source to see
> if I can reproduce, then bisect if so.
>
> $ ARCH=riscv LLVM=1 /usr/bin/time -v make -j128 allmodconfig vmlinux
> ...
>         Elapsed (wall clock) time (h:mm:ss or m:ss): 2:35.68
> ...
>
> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build

OK, it triggered enough of a rebuild that it might take a bit for 
anything to filter out.

Thanks!

>
>>
>> >
>> >>
>> >> Cheers,
>> >> Conor.
>> >
>> >
>> >
>> > --
>> > Thanks,
>> > ~Nick Desaulniers
>
>
>
> -- 
> Thanks,
> ~Nick Desaulniers

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

[Palmer Dabbelt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3612 bytes --]

On Tue, 20 Jun 2023 14:08:33 PDT (-0700), Palmer Dabbelt wrote:
> On Tue, 20 Jun 2023 13:47:07 PDT (-0700), ndesaulniers@google.com wrote:
>> On Tue, Jun 20, 2023 at 4:41 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>
>>> On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
>>> > On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
>>> >>
>>> >> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
>>> >> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>> >> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
>>> >> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
>>> >> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
>>> >> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
>>> >>
>>> >> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
>>> >> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
>>> >> > > >> series is based on 6.4-rc2.
>>> >> > > >
>>> >> > > > Thanks.
>>> >> > >
>>> >> > > Sorry to be so slow here, but I think this is causing LLD to hang on
>>> >> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
>>> >> > > other things I have in flight still.
>>> >> >
>>> >> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
>>> >> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
>>> >>
>>> >> Just FYI Nick, there's been some concurrent work here from different
>>> >> people working on the same thing & the v3 you linked (from Zhangjin) was
>>> >> superseded by this v2 (from Jisheng).
>>> >
>>> > Ah! I've been testing the deprecated patch set, sorry I just looked on
>>> > lore for "dead code" on riscv-linux and grabbed the first thread,
>>> > without noticing the difference in authors or new version numbers for
>>> > distinct series. ok, nevermind my noise.  I'll follow up with the
>>> > correct patch set, sorry!
>>>
>>> Ya, I hadn't even noticed the v3 because I pretty much only look at
>>> patchwork these days.  Like we talked about in IRC, I'm going to go test
>>> the merge of this one and see what's up -- I've got it staged at
>>> <https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>,
>>> though that won't be a stable hash if it's actually broken...
>>
>> Ok, https://lore.kernel.org/linux-riscv/20230523165502.2592-1-jszhang@kernel.org/
>> built for me.  If you're seeing a hang, please let me know what
>> version of LLD you're using and I'll build that tag from source to see
>> if I can reproduce, then bisect if so.
>>
>> $ ARCH=riscv LLVM=1 /usr/bin/time -v make -j128 allmodconfig vmlinux
>> ...
>>         Elapsed (wall clock) time (h:mm:ss or m:ss): 2:35.68
>> ...
>>
>> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build
>
> OK, it triggered enough of a rebuild that it might take a bit for
> anything to filter out.

I'm on LLVM 16.0.2

    $ git describe
    llvmorg-16.0.2
    $ git log | head -n1
    commit 18ddebe1a1a9bde349441631365f0472e9693520

that seems to hang for me -- or at least run for an hour without 
completing, so I assume it's hung.  I'm not wed to 16.0.2, it just 
happens to be the last time I bumped the toolchain.  I'm moving to 
16.0.5 to see if that changes anything.

>
> Thanks!
>
>>
>>>
>>> >
>>> >>
>>> >> Cheers,
>>> >> Conor.
>>> >
>>> >
>>> >
>>> > --
>>> > Thanks,
>>> > ~Nick Desaulniers
>>
>>
>>
>> --
>> Thanks,
>> ~Nick Desaulniers

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

[Palmer Dabbelt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4309 bytes --]

On Tue, 20 Jun 2023 17:13:17 PDT (-0700), Palmer Dabbelt wrote:
> On Tue, 20 Jun 2023 14:08:33 PDT (-0700), Palmer Dabbelt wrote:
>> On Tue, 20 Jun 2023 13:47:07 PDT (-0700), ndesaulniers@google.com wrote:
>>> On Tue, Jun 20, 2023 at 4:41 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>>
>>>> On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
>>>> > On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
>>>> >>
>>>> >> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
>>>> >> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>>> >> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
>>>> >> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
>>>> >> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
>>>> >> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
>>>> >>
>>>> >> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
>>>> >> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
>>>> >> > > >> series is based on 6.4-rc2.
>>>> >> > > >
>>>> >> > > > Thanks.
>>>> >> > >
>>>> >> > > Sorry to be so slow here, but I think this is causing LLD to hang on
>>>> >> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
>>>> >> > > other things I have in flight still.
>>>> >> >
>>>> >> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
>>>> >> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
>>>> >>
>>>> >> Just FYI Nick, there's been some concurrent work here from different
>>>> >> people working on the same thing & the v3 you linked (from Zhangjin) was
>>>> >> superseded by this v2 (from Jisheng).
>>>> >
>>>> > Ah! I've been testing the deprecated patch set, sorry I just looked on
>>>> > lore for "dead code" on riscv-linux and grabbed the first thread,
>>>> > without noticing the difference in authors or new version numbers for
>>>> > distinct series. ok, nevermind my noise.  I'll follow up with the
>>>> > correct patch set, sorry!
>>>>
>>>> Ya, I hadn't even noticed the v3 because I pretty much only look at
>>>> patchwork these days.  Like we talked about in IRC, I'm going to go test
>>>> the merge of this one and see what's up -- I've got it staged at
>>>> <https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>,
>>>> though that won't be a stable hash if it's actually broken...
>>>
>>> Ok, https://lore.kernel.org/linux-riscv/20230523165502.2592-1-jszhang@kernel.org/
>>> built for me.  If you're seeing a hang, please let me know what
>>> version of LLD you're using and I'll build that tag from source to see
>>> if I can reproduce, then bisect if so.
>>>
>>> $ ARCH=riscv LLVM=1 /usr/bin/time -v make -j128 allmodconfig vmlinux
>>> ...
>>>         Elapsed (wall clock) time (h:mm:ss or m:ss): 2:35.68
>>> ...
>>>
>>> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build
>>
>> OK, it triggered enough of a rebuild that it might take a bit for
>> anything to filter out.
>
> I'm on LLVM 16.0.2
>
>     $ git describe
>     llvmorg-16.0.2
>     $ git log | head -n1
>     commit 18ddebe1a1a9bde349441631365f0472e9693520
>
> that seems to hang for me -- or at least run for an hour without
> completing, so I assume it's hung.  I'm not wed to 16.0.2, it just
> happens to be the last time I bumped the toolchain.  I'm moving to
> 16.0.5 to see if that changes anything.

That also takes at least an hour to link.  I tried running on LLVM trunk 
from last night

    $ git log | head -n1
    commit 5e9173c43a9b97c8614e36d6f754317f731e71e9

and that completed.  Just as a curiosity I tried to re-spin it to see 
how long it takes, and it's been running for 23 minutes so far.

So I'm no longer actually sure there's a hang, just something slow.  
That's even more of a grey area, but I think it's sane to call a 1-hour 
link time a regression -- unless it's expected that this is just very 
slow to link?

>
>>
>> Thanks!
>>
>>>
>>>>
>>>> >
>>>> >>
>>>> >> Cheers,
>>>> >> Conor.
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Thanks,
>>>> > ~Nick Desaulniers
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> ~Nick Desaulniers

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

[Conor Dooley]

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

On Wed, Jun 21, 2023 at 07:53:59AM -0700, Palmer Dabbelt wrote:
> On Tue, 20 Jun 2023 17:13:17 PDT (-0700), Palmer Dabbelt wrote:
> > On Tue, 20 Jun 2023 14:08:33 PDT (-0700), Palmer Dabbelt wrote:
> >> On Tue, 20 Jun 2023 13:47:07 PDT (-0700), ndesaulniers@google.com wrote:
> >>> On Tue, Jun 20, 2023 at 4:41 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>>>
> >>>> On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
> >>>> > On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
> >>>> >>
> >>>> >> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
> >>>> >> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> >>>> >> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> >>>> >> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
> >>>> >> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
> >>>> >> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
> >>>> >>
> >>>> >> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
> >>>> >> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
> >>>> >> > > >> series is based on 6.4-rc2.
> >>>> >> > > >
> >>>> >> > > > Thanks.
> >>>> >> > >
> >>>> >> > > Sorry to be so slow here, but I think this is causing LLD to hang on
> >>>> >> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
> >>>> >> > > other things I have in flight still.
> >>>> >> >
> >>>> >> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
> >>>> >> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
> >>>> >>
> >>>> >> Just FYI Nick, there's been some concurrent work here from different
> >>>> >> people working on the same thing & the v3 you linked (from Zhangjin) was
> >>>> >> superseded by this v2 (from Jisheng).
> >>>> >
> >>>> > Ah! I've been testing the deprecated patch set, sorry I just looked on
> >>>> > lore for "dead code" on riscv-linux and grabbed the first thread,
> >>>> > without noticing the difference in authors or new version numbers for
> >>>> > distinct series. ok, nevermind my noise.  I'll follow up with the
> >>>> > correct patch set, sorry!
> >>>>
> >>>> Ya, I hadn't even noticed the v3 because I pretty much only look at
> >>>> patchwork these days.  Like we talked about in IRC, I'm going to go test
> >>>> the merge of this one and see what's up -- I've got it staged at
> >>>> <https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>,
> >>>> though that won't be a stable hash if it's actually broken...
> >>>
> >>> Ok, https://lore.kernel.org/linux-riscv/20230523165502.2592-1-jszhang@kernel.org/
> >>> built for me.  If you're seeing a hang, please let me know what
> >>> version of LLD you're using and I'll build that tag from source to see
> >>> if I can reproduce, then bisect if so.
> >>>
> >>> $ ARCH=riscv LLVM=1 /usr/bin/time -v make -j128 allmodconfig vmlinux
> >>> ...
> >>>         Elapsed (wall clock) time (h:mm:ss or m:ss): 2:35.68
> >>> ...
> >>>
> >>> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build
> >>
> >> OK, it triggered enough of a rebuild that it might take a bit for
> >> anything to filter out.
> >
> > I'm on LLVM 16.0.2
> >
> >     $ git describe
> >     llvmorg-16.0.2
> >     $ git log | head -n1
> >     commit 18ddebe1a1a9bde349441631365f0472e9693520
> >
> > that seems to hang for me -- or at least run for an hour without
> > completing, so I assume it's hung.  I'm not wed to 16.0.2, it just
> > happens to be the last time I bumped the toolchain.  I'm moving to
> > 16.0.5 to see if that changes anything.
> 
> That also takes at least an hour to link.  I tried running on LLVM trunk 
> from last night
> 
>     $ git log | head -n1
>     commit 5e9173c43a9b97c8614e36d6f754317f731e71e9
> 
> and that completed.  Just as a curiosity I tried to re-spin it to see 
> how long it takes, and it's been running for 23 minutes so far.

After some misdirection through stupid user error, I have also
reproduced this for an LLVM=1 build w/ llvmorg-16.0.0

> So I'm no longer actually sure there's a hang, just something slow.  
> That's even more of a grey area, but I think it's sane to call a 1-hour 
> link time a regression -- unless it's expected that this is just very 
> slow to link?

I dunno, if it was only a thing for allyesconfig, then whatever - but
it's gonna significantly increase build times for any large kernels if LLD
is this much slower than LD. Regression in my book.

I'm gonna go and experiment with mixed toolchain builds, I'll report
back..

Cheers,
Conor.

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

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

[Conor Dooley]

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

On Wed, Jun 21, 2023 at 05:42:08PM +0100, Conor Dooley wrote:
> On Wed, Jun 21, 2023 at 07:53:59AM -0700, Palmer Dabbelt wrote:
> > On Tue, 20 Jun 2023 17:13:17 PDT (-0700), Palmer Dabbelt wrote:
> > > On Tue, 20 Jun 2023 14:08:33 PDT (-0700), Palmer Dabbelt wrote:
> > >> On Tue, 20 Jun 2023 13:47:07 PDT (-0700), ndesaulniers@google.com wrote:
> > >>> On Tue, Jun 20, 2023 at 4:41 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > >>>>
> > >>>> On Tue, 20 Jun 2023 13:32:32 PDT (-0700), ndesaulniers@google.com wrote:
> > >>>> > On Tue, Jun 20, 2023 at 4:13 PM Conor Dooley <conor@kernel.org> wrote:
> > >>>> >>
> > >>>> >> On Tue, Jun 20, 2023 at 04:05:55PM -0400, Nick Desaulniers wrote:
> > >>>> >> > On Mon, Jun 19, 2023 at 6:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > >>>> >> > > On Thu, 15 Jun 2023 06:54:33 PDT (-0700), Palmer Dabbelt wrote:
> > >>>> >> > > > On Wed, 14 Jun 2023 09:25:49 PDT (-0700), jszhang@kernel.org wrote:
> > >>>> >> > > >> On Wed, Jun 14, 2023 at 07:49:17AM -0700, Palmer Dabbelt wrote:
> > >>>> >> > > >>> On Tue, 23 May 2023 09:54:58 PDT (-0700), jszhang@kernel.org wrote:
> > >>>> >>
> > >>>> >> > > >> Commit 3b90b09af5be ("riscv: Fix orphan section warnings caused by
> > >>>> >> > > >> kernel/pi") touches vmlinux.lds.S, so to make the merge easy, this
> > >>>> >> > > >> series is based on 6.4-rc2.
> > >>>> >> > > >
> > >>>> >> > > > Thanks.
> > >>>> >> > >
> > >>>> >> > > Sorry to be so slow here, but I think this is causing LLD to hang on
> > >>>> >> > > allmodconfig.  I'm still getting to the bottom of it, there's a few
> > >>>> >> > > other things I have in flight still.
> > >>>> >> >
> > >>>> >> > Confirmed with v3 on mainline (linux-next is pretty red at the moment).
> > >>>> >> > https://lore.kernel.org/linux-riscv/20230517082936.37563-1-falcon@tinylab.org/
> > >>>> >>
> > >>>> >> Just FYI Nick, there's been some concurrent work here from different
> > >>>> >> people working on the same thing & the v3 you linked (from Zhangjin) was
> > >>>> >> superseded by this v2 (from Jisheng).
> > >>>> >
> > >>>> > Ah! I've been testing the deprecated patch set, sorry I just looked on
> > >>>> > lore for "dead code" on riscv-linux and grabbed the first thread,
> > >>>> > without noticing the difference in authors or new version numbers for
> > >>>> > distinct series. ok, nevermind my noise.  I'll follow up with the
> > >>>> > correct patch set, sorry!
> > >>>>
> > >>>> Ya, I hadn't even noticed the v3 because I pretty much only look at
> > >>>> patchwork these days.  Like we talked about in IRC, I'm going to go test
> > >>>> the merge of this one and see what's up -- I've got it staged at
> > >>>> <https://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git/commit/?h=for-next&id=1bd2963b21758a773206a1cb67c93e7a8ae8a195>,
> > >>>> though that won't be a stable hash if it's actually broken...
> > >>>
> > >>> Ok, https://lore.kernel.org/linux-riscv/20230523165502.2592-1-jszhang@kernel.org/
> > >>> built for me.  If you're seeing a hang, please let me know what
> > >>> version of LLD you're using and I'll build that tag from source to see
> > >>> if I can reproduce, then bisect if so.
> > >>>
> > >>> $ ARCH=riscv LLVM=1 /usr/bin/time -v make -j128 allmodconfig vmlinux
> > >>> ...
> > >>>         Elapsed (wall clock) time (h:mm:ss or m:ss): 2:35.68
> > >>> ...
> > >>>
> > >>> Tested-by: Nick Desaulniers <ndesaulniers@google.com> # build
> > >>
> > >> OK, it triggered enough of a rebuild that it might take a bit for
> > >> anything to filter out.
> > >
> > > I'm on LLVM 16.0.2
> > >
> > >     $ git describe
> > >     llvmorg-16.0.2
> > >     $ git log | head -n1
> > >     commit 18ddebe1a1a9bde349441631365f0472e9693520
> > >
> > > that seems to hang for me -- or at least run for an hour without
> > > completing, so I assume it's hung.  I'm not wed to 16.0.2, it just
> > > happens to be the last time I bumped the toolchain.  I'm moving to
> > > 16.0.5 to see if that changes anything.
> > 
> > That also takes at least an hour to link.  I tried running on LLVM trunk 
> > from last night
> > 
> >     $ git log | head -n1
> >     commit 5e9173c43a9b97c8614e36d6f754317f731e71e9
> > 
> > and that completed.  Just as a curiosity I tried to re-spin it to see 
> > how long it takes, and it's been running for 23 minutes so far.
> 
> After some misdirection through stupid user error, I have also
> reproduced this for an LLVM=1 build w/ llvmorg-16.0.0
> 
> > So I'm no longer actually sure there's a hang, just something slow.  
> > That's even more of a grey area, but I think it's sane to call a 1-hour 
> > link time a regression -- unless it's expected that this is just very 
> > slow to link?
> 
> I dunno, if it was only a thing for allyesconfig, then whatever - but
> it's gonna significantly increase build times for any large kernels if LLD
> is this much slower than LD. Regression in my book.
> 
> I'm gonna go and experiment with mixed toolchain builds, I'll report
> back..

Probably as expected, swapping out LLD for LD linked normally & using
gcc-13.1 + LLD hit the same problems with linking.

Cheers,
Conor.

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

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

[Björn Töpel]

Conor Dooley <conor@kernel.org> writes:

[...]

>> So I'm no longer actually sure there's a hang, just something slow.  
>> That's even more of a grey area, but I think it's sane to call a 1-hour 
>> link time a regression -- unless it's expected that this is just very 
>> slow to link?
>
> I dunno, if it was only a thing for allyesconfig, then whatever - but
> it's gonna significantly increase build times for any large kernels if LLD
> is this much slower than LD. Regression in my book.
>
> I'm gonna go and experiment with mixed toolchain builds, I'll report
> back..

I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:

  | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
  |     --toolchain=llvm-16 --runtime docker --directory . -k \
  |     allyesconfig

Took forever, but passed after 2.5h.

CONFIG_CC_VERSION_TEXT="Debian clang version 16.0.6 (++20230610113307+7cbf1a259152-1~exp1~20230610233402.106)"


Björn

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

[Palmer Dabbelt]

On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
> Conor Dooley <conor@kernel.org> writes:
>
> [...]
>
>>> So I'm no longer actually sure there's a hang, just something slow.  
>>> That's even more of a grey area, but I think it's sane to call a 1-hour 
>>> link time a regression -- unless it's expected that this is just very 
>>> slow to link?
>>
>> I dunno, if it was only a thing for allyesconfig, then whatever - but
>> it's gonna significantly increase build times for any large kernels if LLD
>> is this much slower than LD. Regression in my book.
>>
>> I'm gonna go and experiment with mixed toolchain builds, I'll report
>> back..
>
> I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
> HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
>
>   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
>   |     --toolchain=llvm-16 --runtime docker --directory . -k \
>   |     allyesconfig
>
> Took forever, but passed after 2.5h.

Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just 
checking top sometimes), it's at 1.5h but even that seems quite long.

I guess this is sort of up to the LLVM folks: if it's expected that DCE 
takes a very long time to link then I'm not opposed to allowing it, but 
if this is probably a bug in LLD then it seems best to turn it off until 
we sort things out over there.

I think maybe Nick or Nathan is the best bet to know?

> CONFIG_CC_VERSION_TEXT="Debian clang version 16.0.6 (++20230610113307+7cbf1a259152-1~exp1~20230610233402.106)"
>
>
> Björn

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

[Palmer Dabbelt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2330 bytes --]

On Wed, 21 Jun 2023 11:19:31 PDT (-0700), Palmer Dabbelt wrote:
> On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
>> Conor Dooley <conor@kernel.org> writes:
>>
>> [...]
>>
>>>> So I'm no longer actually sure there's a hang, just something slow.
>>>> That's even more of a grey area, but I think it's sane to call a 1-hour
>>>> link time a regression -- unless it's expected that this is just very
>>>> slow to link?
>>>
>>> I dunno, if it was only a thing for allyesconfig, then whatever - but
>>> it's gonna significantly increase build times for any large kernels if LLD
>>> is this much slower than LD. Regression in my book.
>>>
>>> I'm gonna go and experiment with mixed toolchain builds, I'll report
>>> back..
>>
>> I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
>> HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
>>
>>   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
>>   |     --toolchain=llvm-16 --runtime docker --directory . -k \
>>   |     allyesconfig
>>
>> Took forever, but passed after 2.5h.
>
> Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just
> checking top sometimes), it's at 1.5h but even that seems quite long.
>
> I guess this is sort of up to the LLVM folks: if it's expected that DCE
> takes a very long time to link then I'm not opposed to allowing it, but
> if this is probably a bug in LLD then it seems best to turn it off until
> we sort things out over there.
>
> I think maybe Nick or Nathan is the best bet to know?

Looks like it's about 2h for me.  I'm going to drop these from my 
staging tree in the interest of making progress on other stuff, but if 
this is just expected behavior them I'm OK taking them (though that's 
too much compute for me to test regularly):

$ time ../../../../llvm/install/bin/ld.lld -melf64lriscv -z noexecstack -r -o vmlinux.o --whole-archive vmlinux.a --no-whole-archive --start-group ./drivers/firmware/efi/libstub/lib.a --end-group                                                                                                                                    

real    111m50.678s
user    111m18.739s
sys     1m13.147s

>> CONFIG_CC_VERSION_TEXT="Debian clang version 16.0.6 (++20230610113307+7cbf1a259152-1~exp1~20230610233402.106)"
>>
>>
>> Björn

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

[Nick Desaulniers]

On Wed, Jun 21, 2023 at 12:46 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Wed, 21 Jun 2023 11:19:31 PDT (-0700), Palmer Dabbelt wrote:
> > On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
> >> Conor Dooley <conor@kernel.org> writes:
> >>
> >> [...]
> >>
> >>>> So I'm no longer actually sure there's a hang, just something slow.
> >>>> That's even more of a grey area, but I think it's sane to call a 1-hour
> >>>> link time a regression -- unless it's expected that this is just very
> >>>> slow to link?
> >>>
> >>> I dunno, if it was only a thing for allyesconfig, then whatever - but
> >>> it's gonna significantly increase build times for any large kernels if LLD
> >>> is this much slower than LD. Regression in my book.
> >>>
> >>> I'm gonna go and experiment with mixed toolchain builds, I'll report
> >>> back..
> >>
> >> I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
> >> HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
> >>
> >>   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
> >>   |     --toolchain=llvm-16 --runtime docker --directory . -k \
> >>   |     allyesconfig
> >>
> >> Took forever, but passed after 2.5h.
> >
> > Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just
> > checking top sometimes), it's at 1.5h but even that seems quite long.
> >
> > I guess this is sort of up to the LLVM folks: if it's expected that DCE
> > takes a very long time to link then I'm not opposed to allowing it, but
> > if this is probably a bug in LLD then it seems best to turn it off until
> > we sort things out over there.
> >
> > I think maybe Nick or Nathan is the best bet to know?
>
> Looks like it's about 2h for me.  I'm going to drop these from my
> staging tree in the interest of making progress on other stuff, but if
> this is just expected behavior them I'm OK taking them (though that's
> too much compute for me to test regularly):
>
> $ time ../../../../llvm/install/bin/ld.lld -melf64lriscv -z noexecstack -r -o vmlinux.o --whole-archive vmlinux.a --no-whole-archive --start-group ./drivers/firmware/efi/libstub/lib.a --end-group
>
> real    111m50.678s
> user    111m18.739s
> sys     1m13.147s

Ah, I think you meant s/allmodconfig/allyesconfig/ in your initial
report.  That makes more sense, and I can reproduce.  Let me work on a
report.

>
> >> CONFIG_CC_VERSION_TEXT="Debian clang version 16.0.6 (++20230610113307+7cbf1a259152-1~exp1~20230610233402.106)"
> >>
> >>
> >> Björn



--
Thanks,
~Nick Desaulniers

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

[Palmer Dabbelt]

On Thu, 22 Jun 2023 14:40:59 PDT (-0700), ndesaulniers@google.com wrote:
> On Wed, Jun 21, 2023 at 12:46 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>>
>> On Wed, 21 Jun 2023 11:19:31 PDT (-0700), Palmer Dabbelt wrote:
>> > On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
>> >> Conor Dooley <conor@kernel.org> writes:
>> >>
>> >> [...]
>> >>
>> >>>> So I'm no longer actually sure there's a hang, just something slow.
>> >>>> That's even more of a grey area, but I think it's sane to call a 1-hour
>> >>>> link time a regression -- unless it's expected that this is just very
>> >>>> slow to link?
>> >>>
>> >>> I dunno, if it was only a thing for allyesconfig, then whatever - but
>> >>> it's gonna significantly increase build times for any large kernels if LLD
>> >>> is this much slower than LD. Regression in my book.
>> >>>
>> >>> I'm gonna go and experiment with mixed toolchain builds, I'll report
>> >>> back..
>> >>
>> >> I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
>> >> HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
>> >>
>> >>   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
>> >>   |     --toolchain=llvm-16 --runtime docker --directory . -k \
>> >>   |     allyesconfig
>> >>
>> >> Took forever, but passed after 2.5h.
>> >
>> > Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just
>> > checking top sometimes), it's at 1.5h but even that seems quite long.
>> >
>> > I guess this is sort of up to the LLVM folks: if it's expected that DCE
>> > takes a very long time to link then I'm not opposed to allowing it, but
>> > if this is probably a bug in LLD then it seems best to turn it off until
>> > we sort things out over there.
>> >
>> > I think maybe Nick or Nathan is the best bet to know?
>>
>> Looks like it's about 2h for me.  I'm going to drop these from my
>> staging tree in the interest of making progress on other stuff, but if
>> this is just expected behavior them I'm OK taking them (though that's
>> too much compute for me to test regularly):
>>
>> $ time ../../../../llvm/install/bin/ld.lld -melf64lriscv -z noexecstack -r -o vmlinux.o --whole-archive vmlinux.a --no-whole-archive --start-group ./drivers/firmware/efi/libstub/lib.a --end-group
>>
>> real    111m50.678s
>> user    111m18.739s
>> sys     1m13.147s
>
> Ah, I think you meant s/allmodconfig/allyesconfig/ in your initial
> report.  That makes more sense, and I can reproduce.  Let me work on a
> report.

Awesome, thanks!

>
>>
>> >> CONFIG_CC_VERSION_TEXT="Debian clang version 16.0.6 (++20230610113307+7cbf1a259152-1~exp1~20230610233402.106)"
>> >>
>> >>
>> >> Björn

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

[Nathan Chancellor]

On Wed, Jun 21, 2023 at 11:19:31AM -0700, Palmer Dabbelt wrote:
> On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
> > Conor Dooley <conor@kernel.org> writes:
> > 
> > [...]
> > 
> > > > So I'm no longer actually sure there's a hang, just something
> > > > slow.  That's even more of a grey area, but I think it's sane to
> > > > call a 1-hour link time a regression -- unless it's expected
> > > > that this is just very slow to link?
> > > 
> > > I dunno, if it was only a thing for allyesconfig, then whatever - but
> > > it's gonna significantly increase build times for any large kernels if LLD
> > > is this much slower than LD. Regression in my book.
> > > 
> > > I'm gonna go and experiment with mixed toolchain builds, I'll report
> > > back..
> > 
> > I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
> > HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
> > 
> >   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
> >   |     --toolchain=llvm-16 --runtime docker --directory . -k \
> >   |     allyesconfig
> > 
> > Took forever, but passed after 2.5h.
> 
> Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just
> checking top sometimes), it's at 1.5h but even that seems quite long.
> 
> I guess this is sort of up to the LLVM folks: if it's expected that DCE
> takes a very long time to link then I'm not opposed to allowing it, but if
> this is probably a bug in LLD then it seems best to turn it off until we
> sort things out over there.
> 
> I think maybe Nick or Nathan is the best bet to know?

I can confirm a regression with allyesconfig but not allmodconfig using
LLVM 16.0.6 on my 80-core Ampere Altra system.

allmodconfig: 8m 4s
allmodconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n: 7m 4s
allyesconfig: 1h 58m 30s
allyesconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n: 12m 41s

I am sure there is something that ld.lld can do better, given GNU ld
does not have any problems as earlier established, so that should
definitely be explored further. I see Nick already had a response about
writing up a report (I wrote most of this before that email so I am
still sending this one).

However, allyesconfig is pretty special and not really indicative of a
"real world" kernel build in my opinion (which will either be a fully
modular kernel to allow use on a wide range of hardware or a monolithic
kernel with just the drivers needed for a specific platform, which will
be much smaller than allyesconfig); it has given us problems with large
kernels before on other architectures.

CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is already marked with 'depends on
EXPERT' and its help text mentions its perils, so it does not seem
unreasonable to me to add an additional dependency on !COMPILE_TEST so
that allmodconfig and allyesconfig cannot flip this on, something like
the following perhaps?

diff --git a/init/Kconfig b/init/Kconfig
index 32c24950c4ce..25434cbd2a6e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1388,7 +1388,7 @@ config HAVE_LD_DEAD_CODE_DATA_ELIMINATION
 config LD_DEAD_CODE_DATA_ELIMINATION
 	bool "Dead code and data elimination (EXPERIMENTAL)"
 	depends on HAVE_LD_DEAD_CODE_DATA_ELIMINATION
-	depends on EXPERT
+	depends on EXPERT && !COMPILE_TEST
 	depends on $(cc-option,-ffunction-sections -fdata-sections)
 	depends on $(ld-option,--gc-sections)
 	help

If applying that dependency to all architectures is too much, the
selection in arch/riscv/Kconfig could be gated on the same condition.

Cheers,
Nathan

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

[Palmer Dabbelt]

On Thu, 22 Jun 2023 14:53:27 PDT (-0700), nathan@kernel.org wrote:
> On Wed, Jun 21, 2023 at 11:19:31AM -0700, Palmer Dabbelt wrote:
>> On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
>> > Conor Dooley <conor@kernel.org> writes:
>> >
>> > [...]
>> >
>> > > > So I'm no longer actually sure there's a hang, just something
>> > > > slow.  That's even more of a grey area, but I think it's sane to
>> > > > call a 1-hour link time a regression -- unless it's expected
>> > > > that this is just very slow to link?
>> > >
>> > > I dunno, if it was only a thing for allyesconfig, then whatever - but
>> > > it's gonna significantly increase build times for any large kernels if LLD
>> > > is this much slower than LD. Regression in my book.
>> > >
>> > > I'm gonna go and experiment with mixed toolchain builds, I'll report
>> > > back..
>> >
>> > I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
>> > HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
>> >
>> >   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
>> >   |     --toolchain=llvm-16 --runtime docker --directory . -k \
>> >   |     allyesconfig
>> >
>> > Took forever, but passed after 2.5h.
>>
>> Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just
>> checking top sometimes), it's at 1.5h but even that seems quite long.
>>
>> I guess this is sort of up to the LLVM folks: if it's expected that DCE
>> takes a very long time to link then I'm not opposed to allowing it, but if
>> this is probably a bug in LLD then it seems best to turn it off until we
>> sort things out over there.
>>
>> I think maybe Nick or Nathan is the best bet to know?
>
> I can confirm a regression with allyesconfig but not allmodconfig using
> LLVM 16.0.6 on my 80-core Ampere Altra system.
>
> allmodconfig: 8m 4s
> allmodconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n: 7m 4s
> allyesconfig: 1h 58m 30s
> allyesconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n: 12m 41s

Are those backwards?  I'm getting super slow builds after merging the 
patch set, not before -- though apologize in advance if I'm reading it 
wrong, I'm well on my way to falling asleep already ;)

> I am sure there is something that ld.lld can do better, given GNU ld
> does not have any problems as earlier established, so that should
> definitely be explored further. I see Nick already had a response about
> writing up a report (I wrote most of this before that email so I am
> still sending this one).
>
> However, allyesconfig is pretty special and not really indicative of a
> "real world" kernel build in my opinion (which will either be a fully
> modular kernel to allow use on a wide range of hardware or a monolithic
> kernel with just the drivers needed for a specific platform, which will
> be much smaller than allyesconfig); it has given us problems with large
> kernels before on other architectures.

I totally agree that allyesconfig is an oddity, but it's something that 
does get regularly build tested so a big build time hit there is going 
to cause trouble -- maybe not for users, but it'll be a problem for 
maintainers and that's way more likely to get me yelled at ;)

> CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is already marked with 'depends on
> EXPERT' and its help text mentions its perils, so it does not seem
> unreasonable to me to add an additional dependency on !COMPILE_TEST so
> that allmodconfig and allyesconfig cannot flip this on, something like
> the following perhaps?
>
> diff --git a/init/Kconfig b/init/Kconfig
> index 32c24950c4ce..25434cbd2a6e 100644
> --- a/init/Kconfig
> +++ b/init/Kconfig
> @@ -1388,7 +1388,7 @@ config HAVE_LD_DEAD_CODE_DATA_ELIMINATION
>  config LD_DEAD_CODE_DATA_ELIMINATION
>  	bool "Dead code and data elimination (EXPERIMENTAL)"
>  	depends on HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> -	depends on EXPERT
> +	depends on EXPERT && !COMPILE_TEST
>  	depends on $(cc-option,-ffunction-sections -fdata-sections)
>  	depends on $(ld-option,--gc-sections)
>  	help
>
> If applying that dependency to all architectures is too much, the
> selection in arch/riscv/Kconfig could be gated on the same condition.

Is the regression for all ports, or just RISC-V?  I'm fine gating this 
with some sort of Kconfig flag, if it's just impacting RISC-V then it 
seems sane to keep it over here.

> Cheers,
> Nathan

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

[Nathan Chancellor]

On Thu, Jun 22, 2023 at 03:16:51PM -0700, Palmer Dabbelt wrote:
> On Thu, 22 Jun 2023 14:53:27 PDT (-0700), nathan@kernel.org wrote:
> > On Wed, Jun 21, 2023 at 11:19:31AM -0700, Palmer Dabbelt wrote:
> > > On Wed, 21 Jun 2023 10:51:15 PDT (-0700), bjorn@kernel.org wrote:
> > > > Conor Dooley <conor@kernel.org> writes:
> > > >
> > > > [...]
> > > >
> > > > > > So I'm no longer actually sure there's a hang, just something
> > > > > > slow.  That's even more of a grey area, but I think it's sane to
> > > > > > call a 1-hour link time a regression -- unless it's expected
> > > > > > that this is just very slow to link?
> > > > >
> > > > > I dunno, if it was only a thing for allyesconfig, then whatever - but
> > > > > it's gonna significantly increase build times for any large kernels if LLD
> > > > > is this much slower than LD. Regression in my book.
> > > > >
> > > > > I'm gonna go and experiment with mixed toolchain builds, I'll report
> > > > > back..
> > > >
> > > > I took palmer/for-next (1bd2963b2175 ("Merge patch series "riscv: enable
> > > > HAVE_LD_DEAD_CODE_DATA_ELIMINATION"")) for a tuxmake build with llvm-16:
> > > >
> > > >   | ~/src/tuxmake/run -v --wrapper ccache --target-arch riscv \
> > > >   |     --toolchain=llvm-16 --runtime docker --directory . -k \
> > > >   |     allyesconfig
> > > >
> > > > Took forever, but passed after 2.5h.
> > > 
> > > Thanks.  I just re-ran mine 17/trunk LLD under time (rather that just
> > > checking top sometimes), it's at 1.5h but even that seems quite long.
> > > 
> > > I guess this is sort of up to the LLVM folks: if it's expected that DCE
> > > takes a very long time to link then I'm not opposed to allowing it, but if
> > > this is probably a bug in LLD then it seems best to turn it off until we
> > > sort things out over there.
> > > 
> > > I think maybe Nick or Nathan is the best bet to know?
> > 
> > I can confirm a regression with allyesconfig but not allmodconfig using
> > LLVM 16.0.6 on my 80-core Ampere Altra system.
> > 
> > allmodconfig: 8m 4s
> > allmodconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n: 7m 4s
> > allyesconfig: 1h 58m 30s
> > allyesconfig + CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=n: 12m 41s
> 
> Are those backwards?  I'm getting super slow builds after merging the patch
> set, not before -- though apologize in advance if I'm reading it wrong, I'm
> well on my way to falling asleep already ;)

I know I already responded to you around this on IRC but I will do it
here too for the benefit of others following this thread.

These numbers are from the patchset applied on top of dad9774deaf1
("Merge tag 'timers-urgent-2023-06-21' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip"); in other words,
allmodconfig and allyesconfig have CONFIG_LD_DEAD_CODE_DATA_ELIMINATION=y
so turning it off is basically like building allmodconfig and
allyesconfig before the patchset was applied.

> > I am sure there is something that ld.lld can do better, given GNU ld
> > does not have any problems as earlier established, so that should
> > definitely be explored further. I see Nick already had a response about
> > writing up a report (I wrote most of this before that email so I am
> > still sending this one).
> > 
> > However, allyesconfig is pretty special and not really indicative of a
> > "real world" kernel build in my opinion (which will either be a fully
> > modular kernel to allow use on a wide range of hardware or a monolithic
> > kernel with just the drivers needed for a specific platform, which will
> > be much smaller than allyesconfig); it has given us problems with large
> > kernels before on other architectures.
> 
> I totally agree that allyesconfig is an oddity, but it's something that does
> get regularly build tested so a big build time hit there is going to cause
> trouble -- maybe not for users, but it'll be a problem for maintainers and
> that's way more likely to get me yelled at ;)

Agreed. That comment was more around justification for opting out of
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION with these configurations, since
CONFIG_COMPILE_TEST has effective become "am I allmodconfig or
allyesconfig?" nowadays.

> > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is already marked with 'depends on
> > EXPERT' and its help text mentions its perils, so it does not seem
> > unreasonable to me to add an additional dependency on !COMPILE_TEST so
> > that allmodconfig and allyesconfig cannot flip this on, something like
> > the following perhaps?
> > 
> > diff --git a/init/Kconfig b/init/Kconfig
> > index 32c24950c4ce..25434cbd2a6e 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -1388,7 +1388,7 @@ config HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> >  config LD_DEAD_CODE_DATA_ELIMINATION
> >  	bool "Dead code and data elimination (EXPERIMENTAL)"
> >  	depends on HAVE_LD_DEAD_CODE_DATA_ELIMINATION
> > -	depends on EXPERT
> > +	depends on EXPERT && !COMPILE_TEST
> >  	depends on $(cc-option,-ffunction-sections -fdata-sections)
> >  	depends on $(ld-option,--gc-sections)
> >  	help
> > 
> > If applying that dependency to all architectures is too much, the
> > selection in arch/riscv/Kconfig could be gated on the same condition.
> 
> Is the regression for all ports, or just RISC-V?  I'm fine gating this with
> some sort of Kconfig flag, if it's just impacting RISC-V then it seems sane
> to keep it over here.

I am not sure. Only mips selects HAVE_LD_DEAD_CODE_DATA_ELIMINATION
unconditionally and we don't test ARCH=mips all{mod,yes}config (not sure
why off the top of my head). powerpc selects it when using objtool for
mcount generation, which only happens for ppc32 (which we don't test
heavily or with large kernels) or using '-mprofile-kernel', which clang
does not support.

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

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.

Cheers,
Nathan

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

[Nick Desaulniers]

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

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?

> 
> 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

[-- Attachment #2: 0001-riscv-disable-DEAD_CODE_ELIMINATION-for-LLD.patch --]
[-- Type: text/x-diff, Size: 1642 bytes --]

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

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

[Jisheng Zhang]

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.

Thanks
> 
> > 
> > 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
> 

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

[Conor Dooley]

[-- 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 --]

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

[Palmer Dabbelt]

On Sun, 25 Jun 2023 05:43:13 PDT (-0700), Conor Dooley wrote:
> 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

It's been in and out of staging a few times as we tracked down the 
performance regression, but it shouldn't have ever made it to linux-next 
for real.

I'm fine just picking up the patch to disable DCE, I've got a few other 
(hopefully small) things to work through first though.

> 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
>> > 
>> 

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

[Palmer Dabbelt]

On Sun, 25 Jun 2023 05:43:13 PDT (-0700), Conor Dooley wrote:
> 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

It's been in and out of staging a few times as we tracked down the 
performance regression, but it shouldn't have ever made it to linux-next 
for real.

I'm fine just picking up the patch to disable DCE, I've got a few other 
(hopefully small) things to work through first though.

> 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
>> > 
>> 

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

[Fangrui Song]

On Sun, Jun 25, 2023 at 1:06 PM Palmer Dabbelt <palmer@dabbelt.com> wrote:
>
> On Sun, 25 Jun 2023 05:43:13 PDT (-0700), Conor Dooley wrote:
> > 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
>
> It's been in and out of staging a few times as we tracked down the
> performance regression, but it shouldn't have ever made it to linux-next
> for real.
>
> I'm fine just picking up the patch to disable DCE, I've got a few other
> (hopefully small) things to work through first though.

Note: for GCC, -fpatchable-function-entry= (used by
arch/riscv/Kconfig) require GCC 13 for correct garbage collection
semantics.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110729

> > 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
> >> >
> >>
>


-- 
宋方睿