From: Conor Dooley <conor@kernel.org>
To: Saleem Abdulrasool <abdulras@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
ben.dooks@codethink.co.uk, ndesaulniers@google.com,
nathan@kernel.org, Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: avoid enabling vectorized code generation
Date: Mon, 19 Dec 2022 16:51:20 +0000 [thread overview]
Message-ID: <Y6CWiMJRqYRd/S4G@spud> (raw)
In-Reply-To: <CAO8XFHvf9UE8abprkjiKx0RvMCDkyGdpc_MSoFk2pQCyA2qmxA@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3710 bytes --]
On Mon, Dec 19, 2022 at 07:21:32AM -0800, Saleem Abdulrasool wrote:
> On Fri, Dec 16, 2022 at 6:02 PM Conor Dooley <conor@kernel.org> wrote:
> >
> >
> >
> > On 16 December 2022 12:56:23 GMT-08:00, Saleem Abdulrasool <abdulras@google.com> wrote:
> > >On Fri, Dec 16, 2022 at 11:54 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > >>
> > >> On Fri, 16 Dec 2022 11:45:21 PST (-0800), ben.dooks@codethink.co.uk wrote:
> > >> >
> > >> >
> > >> > On 2022-12-16 18:50, Saleem Abdulrasool wrote:
> > >> >> The compiler is free to generate vectorized operations for zero'ing
> > >> >> memory. The kernel does not use the vector unit on RISCV, similar to
> > >> >> architectures such as x86 where we use `-mno-mmx` et al to prevent the
> > >> >> implicit vectorization. Perform a similar check for
> > >> >> `-mno-implicit-float` to avoid this on RISC-V targets.
> > >> >
> > >> > I'm not sure if we should be emitting either of the vector or floating
> > >> > point instrucitons in the kernel without explicitly marking the section
> > >> > of code which is using them such as specific accelerator blocks.
> > >>
> > >> Yep, we can't let the compiler just blindly enable V or F/D. V would
> > >> very much break things as we have no support, but even when that's in
> > >> we'll we at roughly the same spot as F/D are now where we need to handle
> > >> the lazy save/restore bits.
> > >>
> > >> This looks like an LLVM-only option, I see at least some handling here
> > >>
> > >> https://github.com/llvm/llvm-project/blob/a72883b7612f5c00b592da85ed2f1fd81258cc08/clang/lib/Driver/ToolChains/Clang.cpp#L2098
> > >>
> > >> but I don't really know LLVM enough to understand if there's some
> > >> default for `-mimplicit-float` and I can't find anything in the docs.
> > >> If it can be turned on by default and that results in F/D/V instructions
> > >> then we'll need to explicitly turn it off, and that would need to be
> > >> backported.
> > >
> > >Yes, this is an LLVM option, but I think that the `cc-option` wrapping
> > >should help ensure that we do not break the gcc build. This only
> > >recently was added to clang, so an older clang would also miss this
> > >flag. The `-mimplicit-float` is the default AFAIK, which is why we
> > >needed to add this flag in the first place. Enabling V exposed this,
> > >which is why the commit message mentions vector.
> >
> > You've said "enabling V" in the comment and here.
> > By that, do you mean when V support is enabled in clang or when it is enabled in Linux?
>
> Excellent distinction. I meant enabled in the compiler, enabling it
> in the kernel is not yet possible without the pending patchset. This
> makes us robust to when that patchset is merged, but in the meantime,
> this protects against the V extension being enabled in the toolchain.
Ah cool. I figured that it was not possible without the vector patchset
but I was not 100% as it was a wee bit vague ;)
Since V will not be enabled without that patchset, I guess this does not
*have* to go as a fix or to stable?
Per the option's name &
https://github.com/llvm/llvm-project/commit/549231d38e10de7371adb85f5452d42ad42f4201
it may however be better to backport it anyway, in case implicit use of
fp registers does arrive.
You mentioned the gcc build & gcc-12 is fine:
https://patchwork.kernel.org/project/linux-riscv/patch/20221216185012.2342675-1-abdulras@google.com/
Anyway, seems like a sensible addition to me, so:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
I think it may also be good to do:
Link: https://github.com/llvm/llvm-project/commit/549231d38e10de7371adb85f5452d42ad42f4201
Thanks,
Conor.
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
[-- Attachment #2: Type: text/plain, Size: 161 bytes --]
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Conor Dooley <conor@kernel.org>
To: Saleem Abdulrasool <abdulras@google.com>
Cc: Palmer Dabbelt <palmer@dabbelt.com>,
ben.dooks@codethink.co.uk, ndesaulniers@google.com,
nathan@kernel.org, Paul Walmsley <paul.walmsley@sifive.com>,
aou@eecs.berkeley.edu, linux-riscv@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] riscv: avoid enabling vectorized code generation
Date: Mon, 19 Dec 2022 16:51:20 +0000 [thread overview]
Message-ID: <Y6CWiMJRqYRd/S4G@spud> (raw)
In-Reply-To: <CAO8XFHvf9UE8abprkjiKx0RvMCDkyGdpc_MSoFk2pQCyA2qmxA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3710 bytes --]
On Mon, Dec 19, 2022 at 07:21:32AM -0800, Saleem Abdulrasool wrote:
> On Fri, Dec 16, 2022 at 6:02 PM Conor Dooley <conor@kernel.org> wrote:
> >
> >
> >
> > On 16 December 2022 12:56:23 GMT-08:00, Saleem Abdulrasool <abdulras@google.com> wrote:
> > >On Fri, Dec 16, 2022 at 11:54 AM Palmer Dabbelt <palmer@dabbelt.com> wrote:
> > >>
> > >> On Fri, 16 Dec 2022 11:45:21 PST (-0800), ben.dooks@codethink.co.uk wrote:
> > >> >
> > >> >
> > >> > On 2022-12-16 18:50, Saleem Abdulrasool wrote:
> > >> >> The compiler is free to generate vectorized operations for zero'ing
> > >> >> memory. The kernel does not use the vector unit on RISCV, similar to
> > >> >> architectures such as x86 where we use `-mno-mmx` et al to prevent the
> > >> >> implicit vectorization. Perform a similar check for
> > >> >> `-mno-implicit-float` to avoid this on RISC-V targets.
> > >> >
> > >> > I'm not sure if we should be emitting either of the vector or floating
> > >> > point instrucitons in the kernel without explicitly marking the section
> > >> > of code which is using them such as specific accelerator blocks.
> > >>
> > >> Yep, we can't let the compiler just blindly enable V or F/D. V would
> > >> very much break things as we have no support, but even when that's in
> > >> we'll we at roughly the same spot as F/D are now where we need to handle
> > >> the lazy save/restore bits.
> > >>
> > >> This looks like an LLVM-only option, I see at least some handling here
> > >>
> > >> https://github.com/llvm/llvm-project/blob/a72883b7612f5c00b592da85ed2f1fd81258cc08/clang/lib/Driver/ToolChains/Clang.cpp#L2098
> > >>
> > >> but I don't really know LLVM enough to understand if there's some
> > >> default for `-mimplicit-float` and I can't find anything in the docs.
> > >> If it can be turned on by default and that results in F/D/V instructions
> > >> then we'll need to explicitly turn it off, and that would need to be
> > >> backported.
> > >
> > >Yes, this is an LLVM option, but I think that the `cc-option` wrapping
> > >should help ensure that we do not break the gcc build. This only
> > >recently was added to clang, so an older clang would also miss this
> > >flag. The `-mimplicit-float` is the default AFAIK, which is why we
> > >needed to add this flag in the first place. Enabling V exposed this,
> > >which is why the commit message mentions vector.
> >
> > You've said "enabling V" in the comment and here.
> > By that, do you mean when V support is enabled in clang or when it is enabled in Linux?
>
> Excellent distinction. I meant enabled in the compiler, enabling it
> in the kernel is not yet possible without the pending patchset. This
> makes us robust to when that patchset is merged, but in the meantime,
> this protects against the V extension being enabled in the toolchain.
Ah cool. I figured that it was not possible without the vector patchset
but I was not 100% as it was a wee bit vague ;)
Since V will not be enabled without that patchset, I guess this does not
*have* to go as a fix or to stable?
Per the option's name &
https://github.com/llvm/llvm-project/commit/549231d38e10de7371adb85f5452d42ad42f4201
it may however be better to backport it anyway, in case implicit use of
fp registers does arrive.
You mentioned the gcc build & gcc-12 is fine:
https://patchwork.kernel.org/project/linux-riscv/patch/20221216185012.2342675-1-abdulras@google.com/
Anyway, seems like a sensible addition to me, so:
Reviewed-by: Conor Dooley <conor.dooley@microchip.com>
I think it may also be good to do:
Link: https://github.com/llvm/llvm-project/commit/549231d38e10de7371adb85f5452d42ad42f4201
Thanks,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2022-12-19 18:39 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-16 18:50 [PATCH] riscv: avoid enabling vectorized code generation Saleem Abdulrasool
2022-12-16 18:50 ` Saleem Abdulrasool
2022-12-16 19:05 ` Conor Dooley
2022-12-16 19:05 ` Conor Dooley
2022-12-16 19:45 ` Ben Dooks
2022-12-16 19:45 ` Ben Dooks
2022-12-16 19:54 ` Palmer Dabbelt
2022-12-16 19:54 ` Palmer Dabbelt
2022-12-16 20:56 ` Saleem Abdulrasool
2022-12-16 20:56 ` Saleem Abdulrasool
2022-12-17 2:02 ` Conor Dooley
2022-12-17 2:02 ` Conor Dooley
2022-12-19 15:21 ` Saleem Abdulrasool
2022-12-19 15:21 ` Saleem Abdulrasool
2022-12-19 16:51 ` Conor Dooley [this message]
2022-12-19 16:51 ` Conor Dooley
2022-12-21 16:17 ` Bin Meng
2022-12-21 16:17 ` Bin Meng
2022-12-21 17:39 ` Saleem Abdulrasool
2022-12-21 17:39 ` Saleem Abdulrasool
2022-12-22 9:40 ` Bin Meng
2022-12-22 9:40 ` Bin Meng
2022-12-22 15:23 ` Saleem Abdulrasool
2022-12-22 15:23 ` Saleem Abdulrasool
2022-12-23 6:57 ` Bin Meng
2022-12-23 6:57 ` Bin Meng
2022-12-27 15:24 ` Saleem Abdulrasool
2022-12-27 15:24 ` Saleem Abdulrasool
2023-02-08 17:56 ` Palmer Dabbelt
2023-02-08 17:56 ` Palmer Dabbelt
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=Y6CWiMJRqYRd/S4G@spud \
--to=conor@kernel.org \
--cc=abdulras@google.com \
--cc=aou@eecs.berkeley.edu \
--cc=ben.dooks@codethink.co.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.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.