The baseline ISA support requirement for the RISC-V Linux kernel
mandates compressed instructions, so it doesn't make sense for
compressed instruction support to be configurable.
Signed-off-by: Paul Walmsley <[email protected]>
Cc: Atish Patra <[email protected]>
---
arch/riscv/Kconfig | 10 ----------
arch/riscv/Makefile | 2 +-
2 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 59a4727ecd6c..8c5b9329ec46 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -197,16 +197,6 @@ config TUNE_GENERIC
endchoice
-config RISCV_ISA_C
- bool "Emit compressed instructions when building Linux"
- default y
- help
- Adds "C" to the ISA subsets that the toolchain is allowed to emit
- when building Linux, which results in compressed instructions in the
- Linux binary.
-
- If you don't know what to do here, say Y.
-
menu "supported PMU type"
depends on PERF_EVENTS
diff --git a/arch/riscv/Makefile b/arch/riscv/Makefile
index 7a117be8297c..e23e066c55e2 100644
--- a/arch/riscv/Makefile
+++ b/arch/riscv/Makefile
@@ -38,7 +38,7 @@ endif
riscv-march-$(CONFIG_ARCH_RV32I) := rv32ima
riscv-march-$(CONFIG_ARCH_RV64I) := rv64ima
riscv-march-$(CONFIG_FPU) := $(riscv-march-y)fd
-riscv-march-$(CONFIG_RISCV_ISA_C) := $(riscv-march-y)c
+riscv-march-y := $(riscv-march-y)c
KBUILD_CFLAGS += -march=$(subst fd,,$(riscv-march-y))
KBUILD_AFLAGS += -march=$(riscv-march-y)
--
2.22.0
On Tue, Aug 06, 2019 at 07:30:24PM -0700, Paul Walmsley wrote:
>
> The baseline ISA support requirement for the RISC-V Linux kernel
> mandates compressed instructions, so it doesn't make sense for
> compressed instruction support to be configurable.
Looks good,
Reviewed-by: Christoph Hellwig <[email protected]>
On Wed, Aug 7, 2019 at 10:30 AM Paul Walmsley <[email protected]> wrote:
>
>
> The baseline ISA support requirement for the RISC-V Linux kernel
> mandates compressed instructions, so it doesn't make sense for
> compressed instruction support to be configurable.
>
> Signed-off-by: Paul Walmsley <[email protected]>
> Cc: Atish Patra <[email protected]>
>
> ---
> arch/riscv/Kconfig | 10 ----------
> arch/riscv/Makefile | 2 +-
> 2 files changed, 1 insertion(+), 11 deletions(-)
>
Reviewed-by: Bin Meng <[email protected]>
Please do not drop it.
Compressed instruction extension has some specific overhead in small
RISC-V FPGA softcore, especialy in the ones which can't implement the
register file read in a asynchronous manner because of the FPGA
technology.
What are reasons to enforce RVC ?
On Wed, Aug 7, 2019 at 2:29 PM Bin Meng <[email protected]> wrote:
>
> On Wed, Aug 7, 2019 at 10:30 AM Paul Walmsley <[email protected]> wrote:
> >
> >
> > The baseline ISA support requirement for the RISC-V Linux kernel
> > mandates compressed instructions, so it doesn't make sense for
> > compressed instruction support to be configurable.
> >
> > Signed-off-by: Paul Walmsley <[email protected]>
> > Cc: Atish Patra <[email protected]>
> >
> > ---
> > arch/riscv/Kconfig | 10 ----------
> > arch/riscv/Makefile | 2 +-
> > 2 files changed, 1 insertion(+), 11 deletions(-)
> >
>
> Reviewed-by: Bin Meng <[email protected]>
>
> _______________________________________________
> linux-riscv mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-riscv
On Thu, Aug 08, 2019 at 02:18:53PM +0200, Charles Papon wrote:
> Please do not drop it.
>
> Compressed instruction extension has some specific overhead in small
> RISC-V FPGA softcore, especialy in the ones which can't implement the
> register file read in a asynchronous manner because of the FPGA
> technology.
> What are reasons to enforce RVC ?
Because it it the unix platform baseline as stated in the patch.
On 8/12/19 11:03 AM, Christoph Hellwig wrote:
> On Thu, Aug 08, 2019 at 02:18:53PM +0200, Charles Papon wrote:
>> Please do not drop it.
>>
>> Compressed instruction extension has some specific overhead in small
>> RISC-V FPGA softcore, especialy in the ones which can't implement the
>> register file read in a asynchronous manner because of the FPGA
>> technology.
>> What are reasons to enforce RVC ?
>
> Because it it the unix platform baseline as stated in the patch.
>
The same argument could be made for an FPU or MMU, yet there are options
to disable those.
> Because it it the unix platform baseline as stated in the patch.
I know that, but i'm looking for arguments why RVC could't be kept as
an option, especialy it is only an optimisation option without
behavioral/code changes.
That baseline make sense for heavy linux distributions, where you
expect everybody to compile with a baseline set of ISA extentions, to
make binary exchanges easier.
But for smaller systems, i do not see advantages having RVC forced.
On Mon, Aug 12, 2019 at 5:03 PM Christoph Hellwig <[email protected]> wrote:
>
> On Thu, Aug 08, 2019 at 02:18:53PM +0200, Charles Papon wrote:
> > Please do not drop it.
> >
> > Compressed instruction extension has some specific overhead in small
> > RISC-V FPGA softcore, especialy in the ones which can't implement the
> > register file read in a asynchronous manner because of the FPGA
> > technology.
> > What are reasons to enforce RVC ?
>
> Because it it the unix platform baseline as stated in the patch.
On Tue, Aug 13, 2019 at 12:18:22AM +0200, Charles Papon wrote:
> > Because it it the unix platform baseline as stated in the patch.
> I know that, but i'm looking for arguments why RVC could't be kept as
> an option, especialy it is only an optimisation option without
> behavioral/code changes.
>
> That baseline make sense for heavy linux distributions, where you
> expect everybody to compile with a baseline set of ISA extentions, to
> make binary exchanges easier.
> But for smaller systems, i do not see advantages having RVC forced.
I don't fully agree with the benefits, but then again how little
impact using the C extension has on the kernel build I'm now convinced
that keeping it should be ok.
Hi Charles,
On Tue, 13 Aug 2019, Charles Papon wrote:
> > Because it it the unix platform baseline as stated in the patch.
> I know that, but i'm looking for arguments why RVC could't be kept as
> an option, especialy it is only an optimisation option without
> behavioral/code changes.
>
> That baseline make sense for heavy linux distributions, where you
> expect everybody to compile with a baseline set of ISA extentions, to
> make binary exchanges easier.
> But for smaller systems, i do not see advantages having RVC forced.
OK - I agree with you.
Still, I think it would be good if we made this option depend on other
more general kernel configuration parameters for smaller systems. Will
think about this further.
Thanks for commenting on this, and am looking forward to adding a VexRiscv
system to our kernel tests -
- Paul