You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The riscv vector specification lists an embedded configuration: zve32x, and lists that it has a minimum VLEN of 32. Spike accepts this as options on the isa string, and some vector operation work, But many cause an assertion error.
spike: ../riscv/vector_unit.cc:71: T& vectorUnit_t::elt(reg_t, reg_t, bool) [with T = long unsigned int; reg_t = long unsigned int]: Assertion `(VLEN >> 3)/sizeof(T) > 0' failed.
It seems that in the vector implementation internal working copies and masks currently create 64bit types, this causes an assertion to trip.
I think this is the underlying issue faced in #1685. Here is a test-case which activates this with vanilla spike.
Test case
vlen32.S
.globl _start.section .text_start: // Enable vector instructions li x10,0x200 csrs mstatus, x10 li x11,2 vsetvli x11, x0, e32, m1, ta, ma vadd.vx v24, v28, x12, v0.tret
If I adjust the isa string to --isa=rv32imac_zve32x_zvl64b this test-case passes.
Troubleshooting
I've dug into the code a little and it appears that for any instruction with a mask, the mask is created using a VU.elt<uint64_t> type. This correctly trips the assertion since VLEN was configured as 32bits.
I've managed to perform a trivial change mostly in v_ext_macros.h, and some vector instructions, with a direct repalcement uint64_t > uint32_t. This fixes my use_case, but obviously breaks the more typical VLEN >= 64.
I'm happy to rework this into a more general fix and open a PR.
The text was updated successfully, but these errors were encountered:
Summary
The riscv vector specification lists an embedded configuration: zve32x, and lists that it has a minimum VLEN of 32. Spike accepts this as options on the isa string, and some vector operation work, But many cause an assertion error.
It seems that in the vector implementation internal working copies and masks currently create 64bit types, this causes an assertion to trip.
I think this is the underlying issue faced in #1685. Here is a test-case which activates this with vanilla spike.
Test case
vlen32.S
link.ld
Commands to build and run
If I adjust the isa string to
--isa=rv32imac_zve32x_zvl64b
this test-case passes.Troubleshooting
I've dug into the code a little and it appears that for any instruction with a mask, the mask is created using a
VU.elt<uint64_t>
type. This correctly trips the assertion since VLEN was configured as 32bits.I've managed to perform a trivial change mostly in v_ext_macros.h, and some vector instructions, with a direct repalcement uint64_t > uint32_t. This fixes my use_case, but obviously breaks the more typical VLEN >= 64.
I'm happy to rework this into a more general fix and open a PR.
The text was updated successfully, but these errors were encountered: