These command-line options are defined for RISC-V targets:
Set the cost of branches to roughly n instructions.
When generating PIC code, do or don’t allow the use of PLTs. Ignored for non-PIC. The default is -mplt.
Specify integer and floating-point calling convention. ABI-string contains two parts: the size of integer types and the registers used for floating-point types. For example ‘-march=rv64ifd -mabi=lp64d’ means that ‘long’ and pointers are 64-bit (implicitly defining ‘int’ to be 32-bit), and that floating-point values up to 64 bits wide are passed in F registers. Contrast this with ‘-march=rv64ifd -mabi=lp64f’, which still allows the compiler to generate code that uses the F and D extensions but only allows floating-point values up to 32 bits long to be passed in registers; or ‘-march=rv64ifd -mabi=lp64’, in which no floating-point arguments will be passed in registers.
The default for this argument is system dependent, users who want a specific calling convention should specify one explicitly. The valid calling conventions are: ‘ilp32’, ‘ilp32f’, ‘ilp32d’, ‘lp64’, ‘lp64f’, and ‘lp64d’. Some calling conventions are impossible to implement on some ISAs: for example, ‘-march=rv32if -mabi=ilp32d’ is invalid because the ABI requires 64-bit values be passed in F registers, but F registers are only 32 bits wide. There is also the ‘ilp32e’ ABI that can only be used with the ‘rv32e’ architecture. This ABI is not well specified at present, and is subject to change.
Do or don’t use hardware floating-point divide and square root instructions. This requires the F or D extensions for floating-point registers. The default is to use them if the specified architecture has these instructions.
Do or don’t use hardware instructions for integer division. This requires the M extension. The default is to use them if the specified architecture has these instructions.
Generate code for given RISC-V ISA (e.g. ‘rv64im’). ISA strings must be lower-case. Examples include ‘rv64i’, ‘rv32g’, ‘rv32e’, and ‘rv32imaf’.
When -march= is not specified, use the setting from -mcpu.
If both -march and -mcpu= are not specified, the default for this argument is system dependent, users who want a specific architecture extensions should specify one explicitly.
Use architecture of and optimize the output for the given processor, specified by particular CPU name. Permissible values for this option are: ‘sifive-e20’, ‘sifive-e21’, ‘sifive-e24’, ‘sifive-e31’, ‘sifive-e34’, ‘sifive-e76’, ‘sifive-s21’, ‘sifive-s51’, ‘sifive-s54’, ‘sifive-s76’, ‘sifive-u54’, and ‘sifive-u74’.
Optimize the output for the given processor, specified by microarchitecture or particular CPU name. Permissible values for this option are: ‘rocket’, ‘sifive-3-series’, ‘sifive-5-series’, ‘sifive-7-series’, ‘size’, and all valid options for -mcpu=.
When -mtune= is not specified, use the setting from -mcpu, the default is ‘rocket’ if both are not specified.
The ‘size’ choice is not intended for use by end-users. This is used when -Os is specified. It overrides the instruction cost info provided by -mtune=, but does not override the pipeline info. This helps reduce code size while still giving good performance.
Attempt to keep the stack boundary aligned to a 2 raised to num byte boundary. If -mpreferred-stack-boundary is not specified, the default is 4 (16 bytes or 128-bits).
Warning: If you use this switch, then you must build all modules with the same value, including any libraries. This includes the system libraries and startup modules.
Put global and static data smaller than n bytes into a special section (on some targets).
Do or don’t use smaller but slower prologue and epilogue code that uses library function calls. The default is to use fast inline prologues and epilogues.
Do or do not attempt to make more use of compressed load/store instructions by replacing a load/store of ’base register + large offset’ with a new load/store of ’new base + small offset’. If the new base gets stored in a compressed register, then the new load/store can be compressed. Currently targets 32-bit integer load/stores only.
Do not or do generate unaligned memory accesses. The default is set depending on whether the processor we are optimizing for supports fast unaligned access or not.
Generate code for the medium-low code model. The program and its statically defined symbols must lie within a single 2 GiB address range and must lie between absolute addresses -2 GiB and +2 GiB. Programs can be statically or dynamically linked. This is the default code model.
Generate code for the medium-any code model. The program and its statically defined symbols must be within any single 2 GiB address range. Programs can be statically or dynamically linked.
Use or do not use assembler relocation operators when dealing with symbolic addresses. The alternative is to use assembler macros instead, which may limit optimization.
Take advantage of linker relaxations to reduce the number of instructions required to materialize symbol addresses. The default is to take advantage of linker relaxations.
Emit (do not emit) RISC-V attribute to record extra information into ELF objects. This feature requires at least binutils 2.32.
Control how GCC aligns variables and constants of array, structure, or union types. Supported values for type are ‘xlen’ which uses x register width as the alignment value, and ‘natural’ which uses natural alignment. ‘xlen’ is the default.
Generate stack protection code using canary at guard. Supported locations are ‘global’ for a global canary or ‘tls’ for per-thread canary in the TLS block.
With the latter choice the options -mstack-protector-guard-reg=reg and -mstack-protector-guard-offset=offset furthermore specify which register to use as base register for reading the canary, and from what offset from that base register. There is no default register or offset as this is entirely for use within the Linux kernel.