From: Conor Dooley <conor@kernel.org>
To: Palmer Dabbelt <palmer@dabbelt.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>,
Conor Dooley <conor.dooley@microchip.com>,
Dao Lu <daolu@rivosinc.com>, Heiko Stuebner <heiko@sntech.de>,
Guo Ren <guoren@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev
Subject: [PATCH 0/2] (attempt to) Fix RISC-V toolchain extension support detection
Date: Thu, 6 Oct 2022 18:35:19 +0100 [thread overview]
Message-ID: <20221006173520.1785507-1-conor@kernel.org> (raw)
From: Conor Dooley <conor.dooley@microchip.com>
Hey,
This came up due to a report from Kevin @ kernel-ci, who had been
running a mixed configuration of GNU binutils and clang. Their compiler
was relatively recent & supports Zicbom but binutils @ 2.35.2 did not.
Our current checks for extension support only cover the compiler, but it
appears to me that we need to check both the compiler & linker support
in case of "pot-luck" configurations that mix different versions of
LD,AS,CC etc.
Linker support does not seem possible to actually check, since the ISA
string is emitted into the object files - so I put in version checks for
that. The checks have gotten a bit ugly since 32 & 64 bit support need
to be checked independently but ahh well.
As I was going, I fell into the trap of there being duplicated checks
for CC support in both the Makefile and Kconfig, so as part of renaming
the Kconfig symbol to TOOLCHAIN_HAS_FOO, I dropped the extra checks in
the Makefile. This has the added advantage of the TOOLCHAIN_HAS_FOO
symbol for Zihintpause appearing in .config.
I pushed out a version of this that specificly checked for assember
support for LKP to test & it looked /okay/ - but I did some more testing
today and realised that this is redudant & have since dropped the as
check.
I tested locally with a fair few different combinations, to try and
cover each of AS, LD, CC missing support for the extension.
The one that I am left wondering about is Zicsr/Zifencei. Our Makefile
has:
> # Newer binutils versions default to ISA spec version 20191213 which moves some
> # instructions from the I extension to the Zicsr and Zifencei extensions.
> toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
> riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei
I'd like to also move that one to Kconfig rather than the Makefile so
that, again, it shows up in .config etc. But as Zicsr/Zifencei do not
appear to be emitted into the object files it's not a fix and can be a
follow-on patch if my approach here is not entirely off-the-wall.
I am not 100% on the LD/LLD versions that I picked, I went off of a
`git branch -a --contains` of the first commits I found that with
mention of the extension. Please scream if I got it wrong, I'm not
overly familar with where to find this sort of info for the toolchains.
Thanks,
Conor.
Conor Dooley (2):
riscv: fix detection of toolchain Zicbom support
riscv: fix detection of toolchain Zihintpause support
arch/riscv/Kconfig | 17 +++++++++++++----
arch/riscv/Makefile | 6 ++----
arch/riscv/include/asm/vdso/processor.h | 2 +-
3 files changed, 16 insertions(+), 9 deletions(-)
--
2.37.3
_______________________________________________
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: Palmer Dabbelt <palmer@dabbelt.com>,
Nathan Chancellor <nathan@kernel.org>,
Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>,
Conor Dooley <conor.dooley@microchip.com>,
Dao Lu <daolu@rivosinc.com>, Heiko Stuebner <heiko@sntech.de>,
Guo Ren <guoren@kernel.org>,
linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org,
llvm@lists.linux.dev
Subject: [PATCH 0/2] (attempt to) Fix RISC-V toolchain extension support detection
Date: Thu, 6 Oct 2022 18:35:19 +0100 [thread overview]
Message-ID: <20221006173520.1785507-1-conor@kernel.org> (raw)
From: Conor Dooley <conor.dooley@microchip.com>
Hey,
This came up due to a report from Kevin @ kernel-ci, who had been
running a mixed configuration of GNU binutils and clang. Their compiler
was relatively recent & supports Zicbom but binutils @ 2.35.2 did not.
Our current checks for extension support only cover the compiler, but it
appears to me that we need to check both the compiler & linker support
in case of "pot-luck" configurations that mix different versions of
LD,AS,CC etc.
Linker support does not seem possible to actually check, since the ISA
string is emitted into the object files - so I put in version checks for
that. The checks have gotten a bit ugly since 32 & 64 bit support need
to be checked independently but ahh well.
As I was going, I fell into the trap of there being duplicated checks
for CC support in both the Makefile and Kconfig, so as part of renaming
the Kconfig symbol to TOOLCHAIN_HAS_FOO, I dropped the extra checks in
the Makefile. This has the added advantage of the TOOLCHAIN_HAS_FOO
symbol for Zihintpause appearing in .config.
I pushed out a version of this that specificly checked for assember
support for LKP to test & it looked /okay/ - but I did some more testing
today and realised that this is redudant & have since dropped the as
check.
I tested locally with a fair few different combinations, to try and
cover each of AS, LD, CC missing support for the extension.
The one that I am left wondering about is Zicsr/Zifencei. Our Makefile
has:
> # Newer binutils versions default to ISA spec version 20191213 which moves some
> # instructions from the I extension to the Zicsr and Zifencei extensions.
> toolchain-need-zicsr-zifencei := $(call cc-option-yn, -march=$(riscv-march-y)_zicsr_zifencei)
> riscv-march-$(toolchain-need-zicsr-zifencei) := $(riscv-march-y)_zicsr_zifencei
I'd like to also move that one to Kconfig rather than the Makefile so
that, again, it shows up in .config etc. But as Zicsr/Zifencei do not
appear to be emitted into the object files it's not a fix and can be a
follow-on patch if my approach here is not entirely off-the-wall.
I am not 100% on the LD/LLD versions that I picked, I went off of a
`git branch -a --contains` of the first commits I found that with
mention of the extension. Please scream if I got it wrong, I'm not
overly familar with where to find this sort of info for the toolchains.
Thanks,
Conor.
Conor Dooley (2):
riscv: fix detection of toolchain Zicbom support
riscv: fix detection of toolchain Zihintpause support
arch/riscv/Kconfig | 17 +++++++++++++----
arch/riscv/Makefile | 6 ++----
arch/riscv/include/asm/vdso/processor.h | 2 +-
3 files changed, 16 insertions(+), 9 deletions(-)
--
2.37.3
next reply other threads:[~2022-10-06 17:36 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-06 17:35 Conor Dooley [this message]
2022-10-06 17:35 ` [PATCH 0/2] (attempt to) Fix RISC-V toolchain extension support detection Conor Dooley
2022-10-06 17:35 ` [PATCH 1/2] riscv: fix detection of toolchain Zicbom support Conor Dooley
2022-10-06 17:35 ` Conor Dooley
2022-10-06 17:53 ` Heiko Stübner
2022-10-06 17:53 ` Heiko Stübner
2022-10-13 20:22 ` Nathan Chancellor
2022-10-13 20:22 ` Nathan Chancellor
2022-10-13 20:33 ` Conor Dooley
2022-10-13 20:33 ` Conor Dooley
2022-10-13 20:36 ` Nathan Chancellor
2022-10-13 20:36 ` Nathan Chancellor
2022-10-06 17:35 ` [PATCH 2/2] riscv: fix detection of toolchain Zihintpause support Conor Dooley
2022-10-06 17:35 ` Conor Dooley
2022-10-06 18:07 ` Heiko Stübner
2022-10-06 18:07 ` Heiko Stübner
2022-10-13 20:30 ` Nathan Chancellor
2022-10-13 20:30 ` Nathan Chancellor
2022-10-17 15:51 ` [PATCH 0/2] (attempt to) Fix RISC-V toolchain extension support detection Andrew Jones
2022-10-17 15:51 ` Andrew Jones
2022-10-17 16:03 ` Conor Dooley
2022-10-17 16:03 ` Conor Dooley
2022-10-17 16:18 ` Andrew Jones
2022-10-17 16:18 ` Andrew Jones
2022-10-26 13:48 ` Palmer Dabbelt
2022-10-26 13:48 ` Palmer Dabbelt
2022-10-26 13:59 ` Conor Dooley
2022-10-26 13:59 ` Conor Dooley
2022-10-27 21:32 ` Palmer Dabbelt
2022-10-27 21:32 ` Palmer Dabbelt
2022-10-27 22:00 ` Conor Dooley
2022-10-27 22:00 ` Conor Dooley
2022-10-27 22:45 ` Palmer Dabbelt
2022-10-27 22:45 ` 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=20221006173520.1785507-1-conor@kernel.org \
--to=conor@kernel.org \
--cc=conor.dooley@microchip.com \
--cc=daolu@rivosinc.com \
--cc=guoren@kernel.org \
--cc=heiko@sntech.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=llvm@lists.linux.dev \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=palmer@dabbelt.com \
--cc=trix@redhat.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.