Messages in this thread | | | Date | Tue, 15 Nov 2022 22:17:27 +0000 | From | Conor Dooley <> | Subject | Re: [PATCH v12 04/17] riscv: Add vector feature to compile |
| |
On Tue, Nov 15, 2022 at 09:38:53AM -0800, Vineet Gupta wrote: > On 11/13/22 08:16, Conor.Dooley@microchip.com wrote: > > > > +config VECTOR > > > > + bool "VECTOR support" > > > > + depends on GCC_VERSION >= 120000 || CLANG_VERSION >= 130000 > > > > + default n > > > > + help > > > > + Say N here if you want to disable all vector related procedure > > > > + in the kernel. > > > > + > > > > + If you don't know what to do here, say Y. > > > > + > > > > +endmenu > > > "VECTOR" is not really consistent to how the other configs are named; > > > RISCV_ISA_V, RISCV_ISA_VECTOR, RISCV_VECTOR? > > It'd be RISCV_ISA_V to match the others single letter extentions, right? > > Yep. > > > The toolchain dependency check here also seems rather naive. > > Indeed. I can build the code just fine with gcc-11 (and gcc-12), although my > reworked patcheset doesn't include all the orig patches including the > in-kernel xor stuff.
By naive here I meant that checking cc alone is probably not a sufficient check for whether the toolchain supports the extension. What about the assembler etc?
With Zicbom and Zihintpause we ran into problems with mixed usage, eg binutils 2.35 + gcc 12. In his Zicboz series Drew has gone with insn definitions - but while that's okay for something small like Zicboz, do we want to do that for something with as many instructions as vector?
The alternative is cc-option, but that feels a lot less clean than what Drew cooked up here: https://lore.kernel.org/linux-riscv/20221027130247.31634-1-ajones@ventanamicro.com/
I've not checked this because I am lazy, but I am also assuming that whoever put clang-13 in there picked it such that it doesn't require experimental extensions flags. Mostly just writing this to remind myself to check it at some point.
| |