On Wed, May 29, 2024 at 02:49:58PM +0200, Alexandre Ghiti wrote: > Then I missed that, I should have checked the generated code. Is the > extension version "1p0" in '-march=' only required for experimental > extensions? I think so, if my understanding of the message is correct. > But from Conor comment here [1], we should not enable extensions that > are only experimental. In that case, we should be good with this. > > [1] https://lore.kernel.org/linux-riscv/20240528151052.313031-1-alexghiti@xxxxxxxxxxxx/T/#mefb283477bce852f3713cbbb4ff002252281c9d5 Yeah, I tend to agree with Conor on that front. I had not noticed that part of the message when I was looking at other parts of this thread. I could see an argument for allowing experimental extensions for qualification purposes but I think it does create a bit of a support nightmare, especially when there are breaking changes across revisions. > > config EXPERIMENTAL_EXTENSIONS > > bool > > > > config TOOLCHAIN_HAS_ZABHA > > def_bool y > > select EXPERIMENTAL_EXETNSIONS if CC_IS_CLANG > > ... > > > > config TOOLCHAIN_HAS_ZACAS > > def_bool_y > > # ZACAS was experimental until Clang 19: https://github.com/llvm/llvm-project/commit/95aab69c109adf29e183090c25dc95c773215746 > > select EXPERIMENTAL_EXETNSIONS if CC_IS_CLANG && CLANG_VERSION < 190000 > > ... > > > > Then in the Makefile: > > > > ifdef CONFIG_EXPERIMENTAL_EXTENSIONS > > KBUILD_AFLAGS += -menable-experimental-extensions > > KBUILD_CFLAGS += -menable-experimental-extensions > > endif Perhaps with that in mind, maybe EXPERIMENTAL_EXTENSIONS (or whatever) should be a user selectable option and the TOOLCHAIN values depend on it when the user has a clang version that does not support the ratified version. > That's a good idea to me, let's see what Conor thinks [2] > > [2] https://lore.kernel.org/linux-riscv/20240528151052.313031-1-alexghiti@xxxxxxxxxxxx/T/#m1d798dfc4c27e5b6d9e14117d81b577ace123322 FWIW, I think your plan of removing support for the experimental version of the extension and pushing to remove the experimental status in LLVM (especially since it seems like it is ratified like zacas? https://jira.riscv.org/browse/RVS-1685) is probably the best thing going forward. If the LLVM folks are made aware soon, it should be easy to get that change into clang-19, which is branching at the end of July I believe. > Thanks for your thorough review! Thanks for taking LLVM support into consideration :) Cheers, Nathan
