SB+poscscs.litmus had unrecognized opcode

[lihanglin]

Hi maintainer,

When I tried to build the test, I meet the following error

SB+poscscs.c: Assembler messages:
SB+poscscs.c:284: Error: unrecognized opcode `sw.aq.rl t4,0(a5)'
SB+poscscs.c:286: Error: unrecognized opcode `lw.aq.rl a1,0(a3)'
SB+poscscs.c:248: Error: unrecognized opcode `sw.aq.rl t4,0(a5)'
SB+poscscs.c:250: Error: unrecognized opcode `lw.aq.rl a1,0(a3)'

According to RISCV ISA, sw/lw.aq.rl seems not a legal instruction.

The toolchain version I used listed below

Using built-in specs.
COLLECT_GCC=riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=.../libexec/gcc/riscv64-unknown-linux-gnu/7.2.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: .../riscv-gnu-toolchain/riscv-gcc/configure --target=riscv64-unknown-linux-gnu --prefix=/opt/riscv/linux --with-sysroot=.../sysroot --with-system-zlib --enable-shared --enable-tls --enable-languages=c,c++,fortran --disable-libmudflap --disable-libssp --disable-libquadmath --disable-nls --disable-bootstrap --src=.././riscv-gcc --enable-checking=yes --disable-multilib --with-abi=lp64d --with-arch=rv64imafdc
Thread model: posix
gcc version 7.2.0 (GCC) 

[fshaked]

I removed the test.
Thank you for reporting this.

[PeterSewell]

On Fri, 4 Jan 2019 at 09:05, Shaked Flur ***@***.***> wrote: I removed the test. Thank you for reporting this.

(to amplify: this was a test for something supported by the RISC-V concurrency model but that isn't currently encodable)

…

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AErM5q3dDY_Ky507jD7H73-xw85sKseCks5u_xlWgaJpZM4Znhtx> .

[deepsrc]

Hi @PeterSewell
Is it okay to replace the lw.aq and sw.rl in these tests with sequences of lw-fence r,rw and fence rw,w-sw? Will the tests be still valid?

[fshaked]

Hi @PeterSewell Is it okay to replace the lw.aq and sw.rl in these tests with sequences of lw-fence r,rw and fence rw,w-sw? Will the tests be still valid?

Hi @deepsrc,
The change you suggest will result in different behaviour. sw.aq.rl and lw.aq.rl (from the same thread) can not be executed out-of-order with each other, but the fences you use don't prevent this OoO execution between the sw and lw.

[deepsrc]

Hi @fshaked

My question was specific to lw.aq (without release semantics) and sw.rl (without acquire). Is lw followed by fence r,rw (i.e. lw->fence r,rw) an accurate replacement for lw.aq?

Also curious what it means to use acquire semantic with a store or a release semantic with a load? Is sw.aq.rl functionally same as fence rw,rw->sw->fence rw,rw?

[fshaked]

My question was specific to lw.aq (without release semantics) and sw.rl (without acquire). Is lw followed by fence r,rw (i.e. lw->fence r,rw) an accurate replacement for lw.aq?

I think it gets a bit murky because RISC-V doesn't actually have the instructions lw.aq, sw.rl, lw.aq.rl, or sw.aq.rl.
If we look at the closest instructions RV has, lr.aq and sc.rl (wrt lw.aq and sw.rl), those instructions have acquire-RCsc and release-RCsc semantics, respectively.You can then see rule 7 of preserved program order (Volume I: RISC-V Unprivileged ISA, Definition of the RVWMO Memory Model): "a and b both have RCsc annotations''. Hence, lr.aq and sc.rl, even when they access different locations, can't be executed OoO (ish).

Also curious what it means to use acquire semantic with a store or a release semantic with a load? Is sw.aq.rl functionally same as fence rw,rw->sw->fence rw,rw?

Those are defined by rules 5 and 6 of preserved program order: (I'm rephrasing) a memory access (load or store) with acquire annotation can't be executed OoO with any succeeding (in program order) memory access; and a memory access with release annotation can't be executed OoO with any preceding memory access.