openhwgroup / corev-gcc Goto Github PK
View Code? Open in Web Editor NEWLicense: GNU General Public License v2.0
License: GNU General Public License v2.0
This directory contains the GNU Compiler Collection (GCC). The GNU Compiler Collection is free software. See the files whose names start with COPYING for copying permission. The manuals, and some of the runtime libraries, are under different terms; see the individual source files for details. The directory INSTALL contains copies of the installation information as HTML and plain text. The source of this information is gcc/doc/install.texi. The installation information includes details of what is included in the GCC sources and what files GCC installs. See the file gcc/doc/gcc.texi (together with other files that it includes) for usage and porting information. An online readable version of the manual is in the files gcc/doc/gcc.info*. See http://gcc.gnu.org/bugs/ for how to report bugs usefully. Copyright years on GCC source files may be listed using range notation, e.g., 1987-2012, indicating that every year in the range, inclusive, is a copyrightable year that could otherwise be listed individually.
When using corev-openhw-gcc-centos7-20230331 toolchain with F extensions, all interrupt handlers blindly save and restore f registers without looking at Floating-Point state in MSTATUS register.
Moreover it does not save/restore full state as FCSR is missing.
In RISC-V Privilege specification, Machine Status Register (mstatus) section shows some fields for extension states:
When SD equals 1, this means that any of those 3 extensions has been used since they have been enabled or since the last context restore.
So FS/XS/VS should be tested to understand which extension is "Dirty" and needs whole state save and restore when changing the execution context (interrupt route, context switch, etc,...).
When SD is 0, no state needs to be saved/restored and interrupt latency/context switch/... is improved because 33 registers write in memory (generally stack) are not done. Same for the state restore at the end of the interrupt routine/context switch/...
A full description of the FS/XS/VS state transitions is described in Table 3.4
The Event Load Builtin needs to be added to the GCC user manual as RISC-V specific builtin.
This is a stripped down version of a new test program. Attached the pre-processed source and generated assembly code. Compiled with
riscv32-corev-elf-gcc -B/home/jeremy/gittrees/dolphin/build/gcc-stage2/gcc/ /home/jeremy/gittrees/dolphin/gcc/gcc/testsuite/gcc.target/riscv/cv-bitmanip-exec.c -fdiagnostics-plain-output -O1 -march=rv32i_xcvbitmanip -mabi=ilp32 -save-temps -ffat-lto-objects -fno-ident -ffunction-sections -fdata-sections -static -Wl,-gc-sections -specs=nano.specs -lm -Wl,-T/home/jeremy/gittrees/dolphin/toolchain/embecosm-link.ld -save-temps -ggdb -o ./cv-bitmanip-exec.exe
When executed on FPGA, it fails through abort ()
(gdb) bt
#0 0x0000045c in abort ()
#1 0x00000448 in validate (v=<optimised out>, good=<optimised out>)
at /home/jeremy/gittrees/dolphin/gcc/gcc/testsuite/gcc.target/riscv/cv-helpers.h:12
#2 main ()
at /home/jeremy/gittrees/dolphin/gcc/gcc/testsuite/gcc.target/riscv/cv-bitmanip-exec.c:95
(gdb)
We note that while there should be 2 instances each of extract
, extractr
, extractu
and extractur
in the generated output, only 2 instances of extractr
appear.
This only happens with -O1
. At higher or lower optimization levels it all behaves correctly, with the correct number of generated extract instructions.
Update instruction names to match documentation.
Corresponding Binutils issue: openhwgroup/corev-binutils-gdb#101
ARM-like
Pre-* cv.lw rd, (rs1, +/- imm/rs2)!
Post-* cv.lw rd, (rs1), +/-imm/rs2
corev-openhw-gcc-centos7-20231128
CV32E40P v2 with PULP instuctions
Running with this toolchain release, for some cases we see "LA" pseudo instruction does not translate into proper set of instructions:
Result with this toolchain version :
(NOT Expected)
test.S :
kernel_sp:
la x6, kernel_stack_end
Resulting elf/ test.objdump:
0000010c <kernel_sp>:
la x6, kernel_stack_end
10c: 7fc18313 addi x6,x3,2044 # 21704 <kernel_stack_end>
Only 1 instruction "addi" generated.
Whereas with previous toolchain release which I was using corev-openhw-gcc-centos7-20230905 :
(Expected)
The output for the same test was generated correctly as shown:
0000010c <kernel_sp>:
la x6, kernel_stack_end
10c: 00021317 auipc x6,0x21
110: 5f830313 addi x6,x6,1528 # 21704 <kernel_stack_end>
2 instructions auipc and addi generating and building correct label address.
riscv32-corev-elf-gcc -DPULP
-Os -g -static -mabi=ilp32
-march=rv32imc_zicsr_zifencei_xcvhwlp1p0_xcvmem1p0_xcvmac1p0_xcvbi1p0_xcvalu1p0_xcvsimd1p0_xcvbitmanip1p0
-Wall -pedantic -nostartfiles -lcv-verif
/TOOLCHAIN/corev-public-gcc-centos7-20231128/bin/../lib/gcc/riscv32-corev-elf/14.0.0/../../../../riscv32-corev-elf/bin/ld
Simulator questasim (QUESTA_2023.2_1)
Embecosm toolchain: corev-openhw-gcc-centos7-20231128
setenv SIMULATOR vsim
git clone https://github.com/XavierAubert/core-v-verif.git
cd core-v-verif
git checkout cv32e40p/dev_dd
(hash if required -> d6403a919f41c85185a86c3f75876727280f1842 )
cd cv32e40p/sim/uvmt/
make gen_corev-dv test TEST=corev_rand_pulp_hwloop_exception CFG=pulp TEST_CFG_FILE= SIMULATOR=vsim USE_ISS=yes COV=NO RUN_INDEX=1588395466 GEN_START_INDEX=1588395466 SEED=1588395466 CFG_PLUSARGS=+UVM_TIMEOUT=100000
Attached assembly and elf files:
LA_issue.zip
Take cv.bclr
for example. The testcase cv-march-xcvbitmanip-compile-bclr.c has:
// source
// note that 200 == (6 << 5) + 8
res1 = __builtin_riscv_cv_bitmanip_bclr (a, 200);
// check
/* { dg-final { scan-assembler-times "cv\.bclr\t\(\?\:t\[0-6\]\|a\[0-7\]\|s\[1-11\]\),\(\?\:t\[0-6\]\|a\[0-7\]\|s\[1-11\]\),6,8" 1 } } */
assumes the compiled instruction to be like cv.bclr a0, a1, 6, 8
. That is, the lower 5 bits come after the higher 5 bits, or cv.bclr rD, rs1, range[9:5], range[4:0]
.
However in the OpenHW specification: CORE-V builtin names#PULP bit manipulation builtins (32-bit), the lower 5 bits come before the higher 5 bits:
uint32_t __builtin_riscv_cv_bitmanip_bclr (uint32_t i, uint16_t range)
Case a) range is a constant
- result:
rD
- i:
rs1
- range[4:0]:
Is2
(5-bit unsigned value)- range[9:5]:
Is3
(5-bit unsigned value)Generated assembler:
Case a)
cv.bclr rD,rs1,Is2,Is3
FYI, this could be due to a difference in the signature of cv.bclr
, which is cv.bclr rD, rs1, Is3, Is2
in CORE-V Instruction Set Custom Extension#Bit Manipulation Operations where the order of Is3 and Is2 is reversed.
When compiling Embench tests, following error is reported:
riscv32-corev-elf-gcc: error: '-march=rv32imc_zicsr_zifencei_xcvhwlp_xcvmem_xcvmac_xcvbi_xcvalu_xcvsimd_xcvbitmanip': extension 'xcvhwlp' starts with 'x' but is unsupported non-standard extension
For example:
(set
(mem:SI
(plus:SI
(reg/f:SI 136 [ _8 ])
(reg:SI 140 [ivtmp.70 ]))
[ 1 MEM[(int *)_8 + ivtmp.70_3 * 1]+0 S4 A32])
(const_int 0 [0]))
Hello,
I had implemented zcee extension based on riscv-gcc-10.2.0 in last month, and how can I submit it into the designated branch of openhw ?
Definition:
cv.shuffleI0.sci.b rD,rs1,Is2 ;; flgs[7:6] = 0
Current implementation:
cv.shuffleI0.sci.b rD,rs1,Is2 ;; Is2 = 0
Fix required:
This is not an issue but a reminder that the SIMD neg puesdo builtin needs to be implemented to match the builtin specification: https://github.com/openhwgroup/core-v-sw/blob/master/specifications/corev-builtin-spec.md
When I’m trying to build another test with the new toolchain. I encountered the issue below.
This is the prebuild lib I saw in the toolchain folder.
Here are the compiler option used:
LAST_CC = /share/libraries/LIBRARY/0TECHNO/EMBECOSM/TOOLCHAIN/corev-openhw-gcc-centos7-20231128/bin/riscv32-corev-elf-gcc
LAST_CFLAGS = -D__RISCV_CV32__ -D__RISCV_GENERIC__ -DPANTHER -DPANTHER -DWITH_ALLOC -DRTOS_PMSIS -DCLUSTER_COMPILATION -DIS_NOT_VEP -I/scorpion/home/lch/project/panther_release/last/libs/dsp/include -I/drivers/include -fdata-sections -ffunction-sections -DARCHI_CLUSTER_NB_PE=16 -DCLUSTER_COMPILATION -MMD -march=rv32imc_zicsr_zfinx_xcvalu_xcvbi_xcvbitmanip_xcvhwlp_xcvmac_xcvmem_xcvsimd_xcvelw -Wall -Wextra -Wno-unused-variable -Wno-unused-parameter -fdata-sections -fno-common -msmall-data-limit=0 -ffunction-sections -DWITH_ALLOC -Wno-missing-field-initializers -g -O3 -DPRINTF_FLOAT -DMEASUREMENT -I.
LAST_LDFLAGS = -march=rv32imc_zicsr_zfinx_xcvalu_xcvbi_xcvbitmanip_xcvhwlp_xcvmac_xcvmem_xcvsimd_xcvelw -Wl,--gc-sections -Wl,-Map=/net/eagle/volume1/homes/lch/project/examples/dsp/mfcc_f32/build.riscv_vp/panther/build/output.map -static -nostdlib -lm -lgcc
Hi there,
I'm currently moving our RTL+software setup from RI5CY to CV32E40P.
With PULP GCC I got pulp extensions to work (riscv32-unknown-elf-gcc -march=IMXpulpv2
),
and I could see these custom instructions in the disassembly (riscv32-unknown-elf-objdump -Mmarch=IMXpulpv2
).
But with the COREV flow I'm having a hard time to verify that "cv." commands are actually used/included.
(If I use riscv32-corev-elf-gcc -march=rv32im_xcorev
)
I also seems there is no suitable march option with riscv32-corev-elf-objdump anymore.
It would be interesting to know what is the actual support status of these xcorev/pulp extensions in corev-gcc.
Examples I found never used march option *_xcorev, for a reason?
Thanks for your help!
Since the roll-forward a few weeks ago, building the latest commit is producing an ICE when XCVhwlp is enabled.
/home/user/git/openhw/install/riscv32-corev-elf/bin/ranlib libgcov.a
../../../../../../gcc/libgcc/unwind-dw2-fde.c: In function 'fde_radixsort':
../../../../../../gcc/libgcc/unwind-dw2-fde.c:674:1: error: insn does not satisfy its constraints:
674 | }
| ^
(insn 430 429 431 19 (set (reg:SI 70 lpstart0)
(reg:SI 14 a4 [266])) 29242 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 14 a4 [266])
(nil)))
during RTL pass: cprop_hardreg
../../../../../../gcc/libgcc/unwind-dw2-fde.c:674:1: internal compiler error: in extract_constrain_insn, at recog.cc:2713
0xa92ed9 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../../../gcc/gcc/rtl-error.cc:108
movsi_internal
is redefined in gcc/config/riscv/corev.md. The original commit specified move_dest_operand
rather than the current nonimmediate_nonpostinc
, but changing this to how it was in the original patch doesn't fully fix the issue.
Compile the current CORE-V GCC development branch (currently based on commit a6c793a) with xcvhwlp
enabled. (e.g. rv32im_zicsr_xcvhwlp_xcvmem_xcvmac_xcvbi_xcvalu_xcvsimd_xcvbitmanip-ilp32
)
The support for post-increment addressing in #57 does not generate these instructions for -Os
, -Oz
or -Og
. This issues captures the need to add this functionality.
affected the version pre-released at 20230814
/libs/dsp/src/TransformFunctions/dd_dct2_f32.c' -- 'dd_dct2_f32.o'
/tmp/ccAhyHfb.s: Assembler messages:
/tmp/ccAhyHfb.s:75: Error: illegal operands sw a5,(a6),4' /tmp/ccAhyHfb.s:90: Error: illegal operands
sw a5,(a6),4'
/tmp/ccAhyHfb.s:106: Error: illegal operands sw a5,(a3),4' /tmp/ccAhyHfb.s:174: Error: illegal operands
sw a0,(a3),4'
The CORE-V builtins can be enhanced by expanding the rtl for each instruction. This would allow gcc to pattern match to these builtins.
More testing with a simulator would be required.
Added, untested with simulator:
File test.c.tar.gz:
int *c;
int d[12];
int e;
_start ()
{
volatile a = b ();
}
f ()
{
short g, h;
for (; e;)
{
g = 0;
for (; g < 8; g++)
{
h = 0;
for (; h < 4; h++)
d[h] = c[h] = d[0];
}
}
}
b ()
{
return f;
}
riscv32-corev-elf-gcc -march=rv32imac_zicsr_xcvhwlp -mabi=ilp32 -Os \
-Wno-implicit-function-declaration -Wno-implicit-int -Wno-int-conversion \
-nostdlib -nostartfiles -o test.exe test.c
/tmp/ccJN19DD.o: in function `.L9':
test.c:(.text+0x3c): relocation truncated to fit: R_RISCV_CVPCREL_UI12 against `.L3'
collect2: error: ld returned 1 exit status
Using built-in specs.
COLLECT_GCC=riscv32-corev-elf-gcc
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/dolphin/install/libexec/gcc/riscv32-corev-elf/14.0.0/lto-wrapper
Target: riscv32-corev-elf
Configured with: ../../gcc/configure --target=riscv32-corev-elf --prefix=/home/jeremy/gittrees/dolphin/install --with-sysroot=/home/jeremy/gittrees/dolphin/install/riscv32-corev-elf --with-native-system-header-dir=/include --with-newlib --disable-shared --enable-languages=c,c++ --enable-tls --disable-werror --disable-libmudflap --disable-libssp --disable-quadmath --disable-libgomp --disable-nls --enable-multilib --with-multilib-generator='rv32i-ilp32--c rv32ia-ilp32--m rv32im-ilp32--c rv32if-ilp32f-rv32ifd-c rv32iaf-ilp32f-rv32imaf,rv32iafc-d rv32imf-ilp32f-rv32imfd-c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv32ifd-ilp32d--c rv32imfd-ilp32d--c rv32iafd-ilp32d-rv32imafd,rv32iafdc- rv32imafdc-ilp32d--' --with-arch=rv32imac --with-abi=ilp32 : (reconfigured) ../../gcc/configure --target=riscv32-corev-elf --prefix=/home/jeremy/gittrees/dolphin/install --with-sysroot=/home/jeremy/gittrees/dolphin/install/riscv32-corev-elf --with-native-system-header-dir=/include --with-newlib --disable-shared --enable-languages=c,c++ --enable-tls --disable-werror --disable-libmudflap --disable-libssp --disable-quadmath --disable-libgomp --disable-nls --enable-multilib --with-multilib-generator='rv32i-ilp32--c rv32ia-ilp32--m rv32im-ilp32--c rv32if-ilp32f-rv32ifd-c rv32iaf-ilp32f-rv32imaf,rv32iafc-d rv32imf-ilp32f-rv32imfd-c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv32ifd-ilp32d--c rv32imfd-ilp32d--c rv32iafd-ilp32d-rv32imafd,rv32iafdc- rv32imafdc-ilp32d--' --with-arch=rv32imac --with-abi=ilp32
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230928 (experimental) (GCC)
Input file: tmp.S
, which contains a compressible instruction whose compression should be inhibited by .option norvc
:
.option push
.option norvc
addi a0, a0, -1
.option pop
When assembled for RV32IC:
$ /opt/riscv/corev/bin/riscv32-corev-elf-gcc -c -march=rv32ic tmp.S && /opt/riscv/corev/bin/riscv32-corev-elf-objdump -d tmp.o
tmp.o: file format elf32-littleriscv
Disassembly of section .text:
00000000 <.text>:
0: fff50513 add a0,a0,-1
This produces a 32-bit instruction, as requested. However when assembled with RV32IZca (an identical set of instructions):
$ /opt/riscv/corev/bin/riscv32-corev-elf-gcc -c -march=rv32i_zca tmp.S && /opt/riscv/corev/bin/riscv32-corev-elf-objdump -d tmp.o
tmp.o: file format elf32-littleriscv
Disassembly of section .text:
00000000 <.text>:
0: 157d add a0,a0,-1
This results in a 16-bit opcode, even though compressed instructions were disabled via .option norvc
.
I tested with the latest prebuilt toolchain, dated 8th November 2023 on https://www.embecosm.com/resources/tool-chain-downloads/#corev:
$ /opt/riscv/corev/bin/riscv32-corev-elf-gcc --version
riscv32-corev-elf-gcc ('corev-openhw-gcc-ubuntu2204-20230905') 13.0.1 20230313 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Since we don't have an explicit wide instruction prefix like Arm's .w
suffix, ,option norvc
is the only way of inhibiting instruction compression in the assembler. Examples of cases where you may want to do this:
nop
sjr
offsets in auipc; add; jr + imm
sequences, which are faster than la (auipc + addi); add; jr
I thought I'd raise an issue because this seems like it might have been an oversight caused by C vs Zca confusion, rather than a deliberate change in behaviour. Please let me know if this was the wrong place to raise this. RV32IC and RV32IZca are identical instruction sets, so it is at least surprising that assembling the same file will give two different results.
This issue was also raised in CORE-V LLVM openhwgroup/corev-llvm-project#60, where some builtins test fails due to implementation in either CORE-V GCC or CORE-V LLVM.
Status: Links to Work in Progress Branches:
Status: Links to Patch Reviews:
Status: Upstream
Test program (cv-bitmanip-bug.c
):
#include <stdint.h>
#include <stdlib.h>
volatile uint32_t src;
int main ()
{
src = 0xc64a5933;
if (__builtin_riscv_cv_bitmanip_bclr (src, 0x165) != src & 0xfffe001f)
abort ();
}
Compile with:
riscv32-corev-elf-gcc cv-bitmanip-bug.c -O2 -march=rv32i_xcvbitmanip -mabi=ilp32 -specs=nano.specs -lm -Wl,-Tembecosm-link.ld -save-temps -ggdb3 -o ./cv-bitmanip-bug.exe
(where the linker script is in this case suitable for a FPGA X-HEEP CV32E40Pv2 image).
The code hits abort. Looking at the generated code, we see no use of the cv.bclr
instruction:
Dump of assembler code for function main:
0x00000228 <+0>: lui a4,0xc64a6
0x0000022c <+4>: addi a4,a4,-1741 # 0xc64a5933
0x00000230 <+8>: sw a4,-1936(gp)
0x00000234 <+12>: lw a4,-1936(gp)
0x00000238 <+16>: lw a5,-1936(gp)
0x0000023c <+20>: bnez a5,0x248 <main+32>
0x00000240 <+24>: li a0,0
0x00000244 <+28>: ret
0x00000248 <+32>: addi sp,sp,-16
0x0000024c <+36>: sw ra,12(sp)
0x00000250 <+40>: jal 0x3b0 <abort>
We observe that there is no problem if we do not set src
, so this appears to be a misoptimization based on knowing the constant value in src
and (wrongly) working out what the result of cv.bclr
must be from its machine description.
The analogous problem occurs with cv.bset
Instructions like the MAC instructions and SIMD Shuffle and Pack instructions use mixed case e.g. cv.muluRN rD, rs1, rs2, Is3
or cv.shuffleI1.sci.b rD, rs1, Imm6
.
The current implementation uses lowercase.
Although you can implement instructions as mixed case the disassembler will output the instructions in lowercase.
I am raising this as an issue so that we can discuss a way to use mixed case instructions in the assembler and disassembler.
Requires two regression test for hwlp
File test.c (test.c.tar.gz)
char *a;
int b, c;
int
d ()
{
char e = 0;
for (; e < 6; e++)
a[b] |= a[e] |= a[b] |= a[c + e >> 4 * b] |= 80 >> e + 1;
}
riscv32-corev-elf-gcc -march=rv32imac_zicsr_xcvhwlp -mabi=ilp32 -Os -c -o test.o test.c
test.c: In function 'd':
test.c:9:1: error: could not split insn
9 | }
| ^
(insn 70 77 54 (parallel [
(set (reg:SI 70 lpstart0)
(unspec:SI [
(label_ref:SI 54)
] UNSPEC_CV_FOLLOWS))
(set (reg:SI 71 lpend0)
(unspec:SI [
(label_ref:SI 0)
] UNSPEC_CV_LP_END_12))
(set (reg:SI 72 lpcount0)
(const_int 6 [0x6]))
(clobber (reg:SI 15 a5 [204]))
]) "test.c":7:12 discrim 1 244 {doloop_begin_i}
(expr_list:REG_UNUSED (reg:SI 15 a5 [204])
(insn_list:REG_LABEL_OPERAND 54 (insn_list:REG_LABEL_OPERAND 0 (nil)))))
during RTL pass: final
test.c:9:1: internal compiler error: in final_scan_insn_1, at final.cc:2808
0x18b2248 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
../../../gcc/gcc/rtl-error.cc:108
0x139f43e final_scan_insn_1
../../../gcc/gcc/final.cc:2808
0x139f79d final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../../gcc/gcc/final.cc:2887
0x139d4e5 final_1
../../../gcc/gcc/final.cc:1979
0x13a266d rest_of_handle_final
../../../gcc/gcc/final.cc:4240
0x13a29e4 execute
../../../gcc/gcc/final.cc:4318
Please submit a full bug report, with preprocessed source (by using -freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Using built-in specs.
COLLECT_GCC=riscv32-corev-elf-gcc
COLLECT_LTO_WRAPPER=/home/jeremy/gittrees/dolphin/install/libexec/gcc/riscv32-corev-elf/14.0.0/lto-wrapper
Target: riscv32-corev-elf
Configured with: ../../gcc/configure --target=riscv32-corev-elf --prefix=/home/jeremy/gittrees/dolphin/install --with-sysroot=/home/jeremy/gittrees/dolphin/install/riscv32-corev-elf --with-native-system-header-dir=/include --with-newlib --disable-shared --enable-languages=c,c++ --enable-tls --disable-werror --disable-libmudflap --disable-libssp --disable-quadmath --disable-libgomp --disable-nls --enable-multilib --with-multilib-generator='rv32i-ilp32--c rv32ia-ilp32--m rv32im-ilp32--c rv32if-ilp32f-rv32ifd-c rv32iaf-ilp32f-rv32imaf,rv32iafc-d rv32imf-ilp32f-rv32imfd-c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv32ifd-ilp32d--c rv32imfd-ilp32d--c rv32iafd-ilp32d-rv32imafd,rv32iafdc- rv32imafdc-ilp32d--' --with-arch=rv32imac --with-abi=ilp32 : (reconfigured) ../../gcc/configure --target=riscv32-corev-elf --prefix=/home/jeremy/gittrees/dolphin/install --with-sysroot=/home/jeremy/gittrees/dolphin/install/riscv32-corev-elf --with-native-system-header-dir=/include --with-newlib --disable-shared --enable-languages=c,c++ --enable-tls --disable-werror --disable-libmudflap --disable-libssp --disable-quadmath --disable-libgomp --disable-nls --enable-multilib --with-multilib-generator='rv32i-ilp32--c rv32ia-ilp32--m rv32im-ilp32--c rv32if-ilp32f-rv32ifd-c rv32iaf-ilp32f-rv32imaf,rv32iafc-d rv32imf-ilp32f-rv32imfd-c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv32ifd-ilp32d--c rv32imfd-ilp32d--c rv32iafd-ilp32d-rv32imafd,rv32iafdc- rv32imafdc-ilp32d--' --with-arch=rv32imac --with-abi=ilp32
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230928 (experimental) (GCC)
This is a question from llvm openhwgroup/corev-llvm-project#76
I'd like to learn how gcc implements this feature
Event Load Instruction
The event load instruction cv.elw is only supported if the COREV_CLUSTER parameter is set to 1.
But how does the compiler detect the COREV_CLUSTER parameter.
or
The compiler does not require special checking and the user controls whether this extension is enabled or not?
thanks
The testsuite for CoreV SIMD instructions uniformly tests out-of-range bit indices (-32 and 31) for cv.srl/sra/sll/extract/extractu/insert
and treats them as valid code. However, the spec restricts them to a very narrow range, should we treat them as invalid or undefined behavior?
xcvmem mem (reg + reg)
instructions only selected because corev.md is defined higher up than the normal move instructions. This is not good enough for upstream.
Could we merge cv_load with movSI?
corev-openhw-gcc-centos7-20230623
XPULP SIMD ALU Instruction:
avgu.sci.h/b
SIMD ALU operations
cv32e40p-user-manual-en-cv32e40p_v1.3.2.pdf , Table 7.31 SIMD ALU operations
User Manual description:
cv.avgu[.sc,.sci]{.h,.b} rD, rs1, [rs2, Imm6] rD[i] = ((rs1[i] + op2[i]) & {0xFFFF, 0xFF}) >> 1
Note: Immediate is zero-extended, shift is logical.
This issue relates to a recent issue from the cv32e40p core's github repo Issue:
[https://github.com/openhwgroup/cv32e40p/issues/814]
After this referenced issue's (#814) fix, the User Manual is now updated to clarify the cv.avgu.sci Imm6 field to be zero-extended, i.e., unsigned 6-bit Immediate. And the User Manual v1.3.2 now explicitly specifies the Imm6 field to be "Zero-extended" for cv.avgu.sci.h/b instructions.
But at this release version of the toolchain, this User Manual update is not yet reflected in the toolchain, and as a result if the Imm6 field notation used in assembly code is for unsigned 6-bit decimal beyond decimal 31, the toolchain flags this as out-of-range error.
Error Example:
cv.avgu.sci.b a0, t5, 43
Error: immediate value must be 6-bit signed, 43 is out of range
Maybe the team is already aware of this related User Manual update but just raising this issue here to track and notify.
Getting following error when building the cli_test sample project of CORE-V-SDK with latest toolchain(15th Aug 2023), it seems latest toolchain doesn’t have the support for the pseudo instruction ‘csrr’.
With the latest released binaries (see https://www.embecosm.com/resources/tool-chain-downloads/#corev), it seems that the compiler requires version numbers to be specified with the CORE-V extension name. For example:
/home/schiavon/tools/corev-riscv/bin/riscv32-corev-elf-gcc -g -march=rv32imac_ziscr_xcvmem_xcvhwlp_xcvalu_xcvbi_xcvmac_xcvelw_xcvbitmanip_xcvsimd -g -march=rv32imac_ziscr_xcvmem_xcvhwlp_xcvalu_xcvbi_xcvmac_xcvelw_xcvbitmanip_xcvsimd -o CMakeFiles/cmTC_83683.dir/testCCompiler.c.obj -c /home/schiavon/gitdir/davide_obi_fifo/x-heep/sw/build/CMakeFiles/CMakeTmp/testCCompiler.c
Assembler messages:
Error: rv32imac_ziscr_xcvalu_xcvbi_xcvbitmanip_xcvelw_xcvhwlp_xcvmac_xcvmem_xcvsimd: unknown prefixed ISA extension `ziscr'
Instead you have to use
rv32imc_zicsr_zifencei_xcvhwlp1p0_xcvmem1p0_xcvmac1p0_xcvbi1p0_xcvalu1p0_xcvsimd1p0_xcvbitmanip1p0
Version numbers should default and in any case there is only one version!
Toolchain version: corev-openhw-gcc-centos7-20230504
Problem Statement:
In the generated code of __builtin_riscv_cv_bitmanip_insert, value of l2 and l3 is swapped. Initially, I thought it is an implementation issue, later I realized it looks more like a spec inconsistency issue. as you can see below. two different cv.insert templates are given for two documents.
cv.insert rD, rs1, Is3, Is2 | rD[min(Is3+Is2,31):Is2] = rs1[Is3-(max(Is3+Is2,31)-31):0]The rest of the bits of rD are untouched and keep their previous value.Is3 + Is2 must be < 32. |
---|
uint32_t __builtin_riscv_cv_bitmanip_insert (uint32_t i, uint16_t range, uint32_t k)
Case a) range is a constant and (range[9:5] + range [4:0]) <= 32
result, k: rD
i: rs1
range[4:0]: Is2 (5-bit unsigned value)
range[9:5]: Is3 (5-bit unsigned value)
or case b)
result, k: rD
i: rs1
range: rs2
Generated assembler:
Case a)
cv.insert rD,rs1,Is2,Is3
The naming of the constraints is confusing.
Currently implemented as
CV6
: Signed 6 bit constant
CS6
: Unsigned 6 bit constant
The naming of constraints is tricky - 1 or 2 characters and 1 digit, so there isn't much choice. But using S for "Unsigned" seems to be asking for confusion.
The naming for all CORE-V predicates and constraints may need renaming to keep with consistency. Would be nice to come up with a rule for naming constraints so that it is universally understandable. This may also apply to renaming CORE-V operands to correspond to the instruction rather than order e.g. currently implemented b5
and b8
correspond to signed and unsigned 6-bit immediate.
When Hardware Loop feature is automatically generated and used in exception handlers, HWloop CSRs are not saved/restored.
So when returning to main program from exception handler using HWloop, it is corrupted if exception happened during main program HWloop execution.
This could happen with illegal exception, interrupt, debug code and maybe other situations.
To make this user friendly it would be nice to include a header file for all the builtins that have been implemented.
When trying to simulate the interrupt_test for cv32e40s, the latest toolchain (corev-openhw-gcc-centos7-20221031) generates push/pop/popret instructions which in the assembler triggers an error:
steps to reproduce:
CV_SW_TOOLCHAIN=/[PATH]/corev-openhw-gcc-centos7-20221031
CV_SW_PREFIX=riscv32-corev-elf-
make test TEST=interrupt_test SIMULATOR=[your sim] USE_ISS=NO
corev-openhw-gcc-centos7-20230623
SIMD ALU operations
cv32e40p-user-manual-en-cv32e40p_v1.3.2.pdf , Table 7.31 SIMD ALU operations
cv.or.sci.h/b
cv.xor.sci.h/b
cv.and.sci.h/b
User Manual description:
cv.or[.sc,.sci]{.h,.b} rD, rs1, [rs2, Imm6] rD[i] = rs1[i] | op2[i]
cv.xor[.sc,.sci]{.h,.b} rD, rs1, [rs2, Imm6] rD[i] = rs1[i] ^ op2[i]
cv.and[.sc,.sci]{.h,.b} rD, rs1, [rs2, Imm6] rD[i] = rs1[i] & op2[i]
For these instructions' [.sci] or immediate Scalar replication mode, with Imm6 used as scalar operand2, the User Manual currently does not explicitly specify whether the Imm6 operand is "Zero-extended", so in such cases as per the description of [.sci] mode in the user manual, these instructions should consider this immediate operand to be sign-extended and as such the signed decimal notation used in assembly for these cases should be allowed (in-line with other sign-extended instructions in this SIMD ALU instructions category).
But with this release of toolchain, if the Imm6 field is negative decimal notation, the toolchain flags these as errors.
Error Example:
cv.or.sci.b t2, t2, -3
Error: immediate value must be 6-bit unsigned, -3 is out of rangecv.and.sci.h a6, s11, -24
Error: immediate value must be 6-bit unsigned, -24 is out of rangecv.xor.sci.h t1, s11, -13
Error: immediate value must be 6-bit unsigned, -13 is out of range
Repro: int.c:
void __attribute__((noinline)) foobar() {
asm volatile ("" : : : "memory");
}
void __attribute__((interrupt)) handle_exception() {
foobar();
}
Run:
$ riscv32-corev-elf-gcc -march=rv32i_zca_zcmp -c int.c
$ riscv32-corev-elf-objdump -D -j .text int.o
Disassembly:
0000000e <handle_exception>:
e: b85e cm.push {ra,s0},-64
10: 1141 addi sp,sp,-16
12: c416 sw t0,8(sp)
14: c21a sw t1,4(sp)
16: c01e sw t2,0(sp)
18: fea12e23 sw a0,-4(sp)
1c: feb12c23 sw a1,-8(sp)
20: fec12a23 sw a2,-12(sp)
24: fed12823 sw a3,-16(sp)
28: fee12623 sw a4,-20(sp)
2c: fef12423 sw a5,-24(sp)
30: ff012223 sw a6,-28(sp)
34: ff112023 sw a7,-32(sp)
38: fdc12e23 sw t3,-36(sp)
3c: fdd12c23 sw t4,-40(sp)
40: fde12a23 sw t5,-44(sp)
44: fdf12823 sw t6,-48(sp)
48: 0880 addi s0,sp,80
4a: 00000097 auipc ra,0x0
4e: 000080e7 jalr ra # 4a <handle_exception+0x3c>
52: 0001 nop
54: 0141 addi sp,sp,16
56: ba5e cm.pop {ra,s0},64
58: fb012283 lw t0,-80(sp)
5c: fac12303 lw t1,-84(sp)
60: fa812383 lw t2,-88(sp)
64: fa412503 lw a0,-92(sp)
68: fa012583 lw a1,-96(sp)
6c: f9c12603 lw a2,-100(sp)
70: f9812683 lw a3,-104(sp)
74: f9412703 lw a4,-108(sp)
78: f9012783 lw a5,-112(sp)
7c: f8c12803 lw a6,-116(sp)
80: f8812883 lw a7,-120(sp)
84: f8412e03 lw t3,-124(sp)
88: f8012e83 lw t4,-128(sp)
8c: f7c12f03 lw t5,-132(sp)
90: f7812f83 lw t6,-136(sp)
94: 30200073 mret
The address to which t0
is saved is different from the address from which it is restored. Compare to the correct disassembly with -march=-march=rv32i_zca
:
0000000e <handle_exception>:
e: 715d addi sp,sp,-80
10: c686 sw ra,76(sp)
12: c496 sw t0,72(sp)
14: c29a sw t1,68(sp)
16: c09e sw t2,64(sp)
18: de22 sw s0,60(sp)
1a: dc2a sw a0,56(sp)
1c: da2e sw a1,52(sp)
1e: d832 sw a2,48(sp)
20: d636 sw a3,44(sp)
22: d43a sw a4,40(sp)
24: d23e sw a5,36(sp)
26: d042 sw a6,32(sp)
28: ce46 sw a7,28(sp)
2a: cc72 sw t3,24(sp)
2c: ca76 sw t4,20(sp)
2e: c87a sw t5,16(sp)
30: c67e sw t6,12(sp)
32: 0880 addi s0,sp,80
34: 00000097 auipc ra,0x0
38: 000080e7 jalr ra # 34 <handle_exception+0x26>
3c: 0001 nop
3e: 40b6 lw ra,76(sp)
40: 42a6 lw t0,72(sp)
42: 4316 lw t1,68(sp)
44: 4386 lw t2,64(sp)
46: 5472 lw s0,60(sp)
48: 5562 lw a0,56(sp)
4a: 55d2 lw a1,52(sp)
4c: 5642 lw a2,48(sp)
4e: 56b2 lw a3,44(sp)
50: 5722 lw a4,40(sp)
52: 5792 lw a5,36(sp)
54: 5802 lw a6,32(sp)
56: 48f2 lw a7,28(sp)
58: 4e62 lw t3,24(sp)
5a: 4ed2 lw t4,20(sp)
5c: 4f42 lw t5,16(sp)
5e: 4fb2 lw t6,12(sp)
60: 6161 addi sp,sp,80
62: 30200073 mret
I'm using the latest prebuilt corev-gcc from here: https://www.embecosm.com/resources/tool-chain-downloads/#corev
$ riscv32-corev-elf-gcc --version
riscv32-corev-elf-gcc ('corev-openhw-gcc-ubuntu2004-20230310') 12.0.1 20220422 (experimental)
Hi, @jessicamills
In zcee, zext.* and sext.* 's instructions needs the B-extension subsets Zba and Zbb . I had not found them in corev-gcc .
I want to know how to solve this problem.
Thanks
Liao Shihua
This was originally raised as binutils-gdb issue #47 , but is a GCC issue.
I got an error message when using the toolchain on an internal code base when doing riscv32-corev-elf-objdump -S <path/to/ELF>
:
corev-openhw-gcc-ubuntu2004-20221031/bin/riscv32-corev-elf-objdump: DWARF error: mangled line number section
The code was compiled with the following flags: -mabi=ilp32e -march=rv32emzicsr_zba_zbb_zbc_zbs_zca_zcb_zcmb_zcmt
GCC build info (downloaded from embecosm website):
Using built-in specs.
COLLECT_GCC=/home/tone/riscv-gcc/corev-openhw-gcc-ubuntu2004-20221031/bin/riscv32-corev-elf-gcc
COLLECT_LTO_WRAPPER=/home/tone/riscv-gcc/corev-openhw-gcc-ubuntu2004-20221031/bin/../libexec/gcc/riscv32-corev-elf/12.0.1/lto-wrapper
Target: riscv32-corev-elf
Configured with: ../../gcc/configure --target=riscv32-corev-elf --prefix=/build/workspace/corev-gcc-ubuntu2004/install --with-sysroot=/build/workspace/corev-gcc-ubuntu2004/install/riscv32-corev-elf --with-native-system-header-dir=/include --with-newlib --disable-shared --enable-languages=c,c++ --enable-tls --disable-werror --disable-libmudflap --disable-libssp --disable-quadmath --disable-libgomp --disable-nls --enable-multilib --with-multilib-generator='rv32e-ilp32e--c rv32ea-ilp32e--m rv32em-ilp32e--c rv32eac-ilp32e-- rv32emac-ilp32e-- rv32i-ilp32--c rv32ia-ilp32--m rv32im-ilp32--c rv32if-ilp32f-rv32ifd-c rv32iaf-ilp32f-rv32imaf,rv32iafc-d rv32imf-ilp32f-rv32imfd-c rv32iac-ilp32-- rv32imac-ilp32-- rv32imafc-ilp32f-rv32imafdc- rv32ifd-ilp32d--c rv32imfd-ilp32d--c rv32iafd-ilp32d-rv32imafd,rv32iafdc- rv32imafdc-ilp32d-- rv64i-lp64--c rv64ia-lp64--m rv64im-lp64--c rv64if-lp64f-rv64ifd-c rv64iaf-lp64f-rv64imaf,rv64iafc-d rv64imf-lp64f-rv64imfd-c rv64iac-lp64-- rv64imac-lp64-- rv64imafc-lp64f-rv64imafdc- rv64ifd-lp64d--m,c rv64iafd-lp64d-rv64imafd,rv64iafdc- rv64imafdc-lp64d--' --with-arch=rv32imac --with-abi=ilp32 --with-bugurl=''\''https://www.embecosm.com'\''' --with-pkgversion=''\''corev-openhw-gcc-ubuntu2004-20221031'\'''
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.0.1 20220422 (experimental) ('corev-openhw-gcc-ubuntu2004-20221031')
I don't yet know how much code I can share so I'll have to get back to you on how to make a minimal viable example to reproduce if needed.
test.c:
#include <stdio.h>
#include <stdlib.h>
void test_uint64_shl_easy(void)
{
unsigned long long p1 = 0x1111111122222222ULL;
unsigned long long r = 0x3333333344444444ULL;
unsigned int res = 0;
printf("test shl\n");
if (p1 << 1 == r)
{
res = 1;
}
return;
}
int main(void)
{
test_uint64_shl_easy();
printf("test main\n");
return 0;
}
Build:
riscv32-unknown-elf-gcc -mabi=ilp32 -march=rv32ima_zca_zcb_zcmp_zcmt -mcmodel=medany -nostartfiles -fno-common -O0 test.c -o test
riscv32-unknown-elf-objdump -d test > test.asm
Disassembly:
ra register is modified when unsigned long long p1
is written to the stack
When compiling Embench tests, following errors are reported:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.