All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nick Desaulniers <ndesaulniers@google.com>
To: twd2 <twd2.me@gmail.com>
Cc: palmer@dabbelt.com, paul.walmsley@sifive.com,
	aou@eecs.berkeley.edu,  linux-riscv@lists.infradead.org,
	nathan@kernel.org, llvm@lists.linux.dev,
	 Fangrui Song <maskray@google.com>
Subject: Re: [PATCH v2] RISC-V: build: Allow LTO to be selected
Date: Fri, 13 May 2022 12:30:06 -0700	[thread overview]
Message-ID: <CAKwvOdnSRA_1wO8bb3tuGCunPjx_pQDi2_0O9yQLbk-TRR3dyA@mail.gmail.com> (raw)
In-Reply-To: <30f9c99e-9bc4-9369-a533-7b454a213403@gmail.com>

On Fri, May 13, 2022 at 11:28 AM twd2 <twd2.me@gmail.com> wrote:
>
> 在 2022/5/13 5:34, Nick Desaulniers 写道:
> > On Thu, May 12, 2022 at 1:56 PM Wende Tan <twd2.me@gmail.com> wrote:
> >> Allow LTO to be selected for RISC-V, only when LLD >= 14, since there is an
> >> issue [1] in prior LLD versions that prevents LLD to generate proper
> >> machine code for RISC-V when writing `nop`s.
> >>
> >> I have tested enabling LTO for `defconfig`. The LLD took ~2m21s and ~3GiB
> >> on our Intel Xeon Gold 6140 server and produced an 18MiB Image. The image
> >> can boot to shell using an archriscv rootfs on QEMU.
> >>
> >> I have also tested it for `allyesconfig` without COMPILE_TEST, FTRACE,
> >> KASAN, and GCOV. The LLD took ~7h03m and ~335GiB on the server,
> > Haha! That's ok, allyesconfig is not expected to boot for any
> > architectures AFAIK. For CI, we simply verify we can build them; we
> > boot test everything but allyesconfig and allmodconfig (and
> > architectures which don't yet have qemu ports).  It helps detect when
> > assembler sources don't use enough encoding space when referenced
> > external symbols are too far away for larger images, IME.
> >
> > That's a long time; first time I've seen a number from someone trying
> > to LTO allyesconfig!
> >
> >> successfully producing a 1.7GiB Image. Unfortunately, we cannot boot this
> >> image because the `create_kernel_page_table()` -> `alloc_pmd_early()` ->
> >> `BUG_ON()` logic limits the image to be < 1GiB. Maybe we can fix it in a
> >> separate patch further.
> >>
> >> [1] https://github.com/llvm/llvm-project/issues/50505, resolved by LLVM
> >>     commit e63455d5e0e5 ("[MC] Use local MCSubtargetInfo in writeNops")
> > So looking at that change, it doesn't look like it touches LLD at all.
> > To me it touches both the assembler and the object streamer, which is
> > used by the compiler (and assembler) to stream instructions directly
> > into an object file (without the need for an external assembler).
> >
> > That makes me think that
> > CLANG_VERSION >= 140000
> > would be more appropriate than
> > LLD_VERSION >= 140000
> >
> > WDYT?
>
>
> It seems that when LTO is enabled, the compiler (clang) only generates bitcode, and LLD collects all the bitcode, does LTO, and generates machine code (assembly) and ELF object files? Actually, the error message in #50505 was originally reported by LLD. So I'd like to check LLD_VERSION here.

Ah, that's right. Ok, LGTM.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
>
> >
> > Also, I'm curious if the LLVM patch you had me commit for you recently
> > is at all related or necessary for this? If so, then the version check
> > should probably be against clang-15, not clang-14.
> > https://github.com/llvm/llvm-project/commit/6baaad740a5abb4bfcff022a8114abb4eea66a2d
>
>
> Aha, that patch is for enabling LTO for allyesconfig (especially, with xfs and overlayfs). I think that patch is not mandatory for enabling LTO for RISC-V.
>
>
> > Anyways, I just did a build+boot (in qemu) test of defconfig+thinlto
> > and defconfig+lto. LGTM
> >
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>
>
> Thanks,
> Wende
>
>
> >> Tested-by: Wende Tan <twd2.me@gmail.com>
> >> Signed-off-by: Wende Tan <twd2.me@gmail.com>
> >> ---
> >> v2:
> >> - Some textual changes suggested by Nick.
> >> - Drop the changes to `arch/riscv/Makefile`, since the LLVM issue is filed
> >>   and resolved.
> >> - Drop the unnecessary changes to `arch/riscv/kernel/vdso/Makefile`.
> >>
> >> v1: https://lore.kernel.org/linux-riscv/20210719205208.1023221-1-twd2.me@gmail.com/
> >> ---
> >>  arch/riscv/Kconfig | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> >> index 00fd9c548f26..c55f6b95e5af 100644
> >> --- a/arch/riscv/Kconfig
> >> +++ b/arch/riscv/Kconfig
> >> @@ -38,6 +38,10 @@ config RISCV
> >>         select ARCH_SUPPORTS_ATOMIC_RMW
> >>         select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
> >>         select ARCH_SUPPORTS_HUGETLBFS if MMU
> >> +       # LLD >= 14:
> >> +       # - https://github.com/llvm/llvm-project/issues/50505
> >> +       select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000
> >> +       select ARCH_SUPPORTS_LTO_CLANG_THIN if LLD_VERSION >= 140000
> >>         select ARCH_USE_MEMTEST
> >>         select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> >>         select ARCH_WANT_FRAME_POINTERS
> >> --
> >> 2.25.1
> >>



-- 
Thanks,
~Nick Desaulniers

WARNING: multiple messages have this Message-ID (diff)
From: Nick Desaulniers <ndesaulniers@google.com>
To: twd2 <twd2.me@gmail.com>
Cc: palmer@dabbelt.com, paul.walmsley@sifive.com,
	aou@eecs.berkeley.edu,  linux-riscv@lists.infradead.org,
	nathan@kernel.org, llvm@lists.linux.dev,
	 Fangrui Song <maskray@google.com>
Subject: Re: [PATCH v2] RISC-V: build: Allow LTO to be selected
Date: Fri, 13 May 2022 12:30:06 -0700	[thread overview]
Message-ID: <CAKwvOdnSRA_1wO8bb3tuGCunPjx_pQDi2_0O9yQLbk-TRR3dyA@mail.gmail.com> (raw)
In-Reply-To: <30f9c99e-9bc4-9369-a533-7b454a213403@gmail.com>

On Fri, May 13, 2022 at 11:28 AM twd2 <twd2.me@gmail.com> wrote:
>
> 在 2022/5/13 5:34, Nick Desaulniers 写道:
> > On Thu, May 12, 2022 at 1:56 PM Wende Tan <twd2.me@gmail.com> wrote:
> >> Allow LTO to be selected for RISC-V, only when LLD >= 14, since there is an
> >> issue [1] in prior LLD versions that prevents LLD to generate proper
> >> machine code for RISC-V when writing `nop`s.
> >>
> >> I have tested enabling LTO for `defconfig`. The LLD took ~2m21s and ~3GiB
> >> on our Intel Xeon Gold 6140 server and produced an 18MiB Image. The image
> >> can boot to shell using an archriscv rootfs on QEMU.
> >>
> >> I have also tested it for `allyesconfig` without COMPILE_TEST, FTRACE,
> >> KASAN, and GCOV. The LLD took ~7h03m and ~335GiB on the server,
> > Haha! That's ok, allyesconfig is not expected to boot for any
> > architectures AFAIK. For CI, we simply verify we can build them; we
> > boot test everything but allyesconfig and allmodconfig (and
> > architectures which don't yet have qemu ports).  It helps detect when
> > assembler sources don't use enough encoding space when referenced
> > external symbols are too far away for larger images, IME.
> >
> > That's a long time; first time I've seen a number from someone trying
> > to LTO allyesconfig!
> >
> >> successfully producing a 1.7GiB Image. Unfortunately, we cannot boot this
> >> image because the `create_kernel_page_table()` -> `alloc_pmd_early()` ->
> >> `BUG_ON()` logic limits the image to be < 1GiB. Maybe we can fix it in a
> >> separate patch further.
> >>
> >> [1] https://github.com/llvm/llvm-project/issues/50505, resolved by LLVM
> >>     commit e63455d5e0e5 ("[MC] Use local MCSubtargetInfo in writeNops")
> > So looking at that change, it doesn't look like it touches LLD at all.
> > To me it touches both the assembler and the object streamer, which is
> > used by the compiler (and assembler) to stream instructions directly
> > into an object file (without the need for an external assembler).
> >
> > That makes me think that
> > CLANG_VERSION >= 140000
> > would be more appropriate than
> > LLD_VERSION >= 140000
> >
> > WDYT?
>
>
> It seems that when LTO is enabled, the compiler (clang) only generates bitcode, and LLD collects all the bitcode, does LTO, and generates machine code (assembly) and ELF object files? Actually, the error message in #50505 was originally reported by LLD. So I'd like to check LLD_VERSION here.

Ah, that's right. Ok, LGTM.

Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>

>
>
> >
> > Also, I'm curious if the LLVM patch you had me commit for you recently
> > is at all related or necessary for this? If so, then the version check
> > should probably be against clang-15, not clang-14.
> > https://github.com/llvm/llvm-project/commit/6baaad740a5abb4bfcff022a8114abb4eea66a2d
>
>
> Aha, that patch is for enabling LTO for allyesconfig (especially, with xfs and overlayfs). I think that patch is not mandatory for enabling LTO for RISC-V.
>
>
> > Anyways, I just did a build+boot (in qemu) test of defconfig+thinlto
> > and defconfig+lto. LGTM
> >
> > Tested-by: Nick Desaulniers <ndesaulniers@google.com>
>
>
> Thanks,
> Wende
>
>
> >> Tested-by: Wende Tan <twd2.me@gmail.com>
> >> Signed-off-by: Wende Tan <twd2.me@gmail.com>
> >> ---
> >> v2:
> >> - Some textual changes suggested by Nick.
> >> - Drop the changes to `arch/riscv/Makefile`, since the LLVM issue is filed
> >>   and resolved.
> >> - Drop the unnecessary changes to `arch/riscv/kernel/vdso/Makefile`.
> >>
> >> v1: https://lore.kernel.org/linux-riscv/20210719205208.1023221-1-twd2.me@gmail.com/
> >> ---
> >>  arch/riscv/Kconfig | 4 ++++
> >>  1 file changed, 4 insertions(+)
> >>
> >> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> >> index 00fd9c548f26..c55f6b95e5af 100644
> >> --- a/arch/riscv/Kconfig
> >> +++ b/arch/riscv/Kconfig
> >> @@ -38,6 +38,10 @@ config RISCV
> >>         select ARCH_SUPPORTS_ATOMIC_RMW
> >>         select ARCH_SUPPORTS_DEBUG_PAGEALLOC if MMU
> >>         select ARCH_SUPPORTS_HUGETLBFS if MMU
> >> +       # LLD >= 14:
> >> +       # - https://github.com/llvm/llvm-project/issues/50505
> >> +       select ARCH_SUPPORTS_LTO_CLANG if LLD_VERSION >= 140000
> >> +       select ARCH_SUPPORTS_LTO_CLANG_THIN if LLD_VERSION >= 140000
> >>         select ARCH_USE_MEMTEST
> >>         select ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT if MMU
> >>         select ARCH_WANT_FRAME_POINTERS
> >> --
> >> 2.25.1
> >>



-- 
Thanks,
~Nick Desaulniers

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  parent reply	other threads:[~2022-05-13 19:30 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 20:55 [PATCH v2] RISC-V: build: Allow LTO to be selected Wende Tan
2022-05-12 20:55 ` Wende Tan
2022-05-12 21:34 ` Nick Desaulniers
2022-05-12 21:34   ` Nick Desaulniers
2022-05-13 18:28   ` twd2
2022-05-13 18:28     ` twd2
2022-05-13 18:58     ` Fāng-ruì Sòng
2022-05-13 18:58       ` Fāng-ruì Sòng
2022-05-13 19:30     ` Nick Desaulniers [this message]
2022-05-13 19:30       ` Nick Desaulniers
2022-05-13 19:31       ` Fāng-ruì Sòng
2022-05-13 19:31         ` Fāng-ruì Sòng
2022-07-01  4:42         ` twd2
2022-07-01  4:42           ` twd2
2022-10-05  1:57 ` Palmer Dabbelt
2022-10-05  1:57   ` Palmer Dabbelt
2022-10-05  2:19   ` Wende Tan
2022-10-05  2:19     ` Wende Tan
2022-10-28 22:57   ` Nathan Chancellor
2022-10-28 22:57     ` Nathan Chancellor

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=CAKwvOdnSRA_1wO8bb3tuGCunPjx_pQDi2_0O9yQLbk-TRR3dyA@mail.gmail.com \
    --to=ndesaulniers@google.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=linux-riscv@lists.infradead.org \
    --cc=llvm@lists.linux.dev \
    --cc=maskray@google.com \
    --cc=nathan@kernel.org \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=twd2.me@gmail.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.