Use of pseudo instructions in compliance tests.

[jeremybennett]

This is a discussion point - I am not clear what the correct answer is.

In issue #105, I note that the regression tests use one of the assembler pseudo instructions, la, in a non-standard way.

        la rd, symbol

is a shorthand for

        auipc rd, symbol[31:12]
        addi rd, rd, symbol[11:0]

This issue is to raise the question of whether the compliance tests should use pseudo instructions at all. RISC-V is perhaps unusual in having quite so many pseudo instructions (I think there are 47 at present). As issue #105 shows, not all are reliably implemented. In part they are a legacy of the attempt to bring up a compiler tool chain very quickly nearly a decade ago.

Pseudo instructions are inherently opaque, and can potentially change (for example choice of insturction for nop), although this seems less likely for RISC-V, since they form part of the standard.

As we discussed in the early days of the compliance standard, having to use an assembler at all is already a compromise. We are testing compliance of implementations of the architecture, not compliance of the assembler, and as we see this is an area where assemblers differ.

I propose that the compliance test suite should use no pseudo instructions and stick strictly to plain assembler opcodes.

[aswaterman]

This issue is to raise the question of whether the compliance tests should use pseudo instructions at all.

IMO, this is only one step away from suggesting the compliance tests shouldn't rely on the assembler at all, and should instead rewrite its own.

Inconsistencies in the documentation and implementation of pseudoinstructions should be rectified, but that's a bad reason to stop using them.

[jeremybennett]

@aswaterman I agree that the documentation/implementation should be fixed, but that wasn't really the point I was making. It was just what brought it to my attention.

Compliance is (amongst other things), checking that he instructions of the machine behave as the standard says they should. So I think it is better to be explicit about the instructions that are being tested.

[aswaterman]

@jeremybennett when you're testing auipc, it makes sense to write that instruction explicitly, rather than using la as a proxy for it. When you're testing sfence.vma, you shouldn't feel ashamed to use la as a proxy for auipc.

[simon5656]

I think it is wrong to use pseudo instructions in compliance tests and is unnecessary and it should be mandated that compliance tests DO NOT use pseudos. Compliance testing is about the hardware and not the software tools... Also - use of pseudo instructions causes trouble for log/dissembler based functional coverage tools used to test compliance coverage which either report wrong coverage or have to convert all pseudos to real instructions. Just to be clear - I would support mandating that all compliance tests do not use pseudo instructions. thanks Simon

…

________________________________ From: Jeremy Bennett <notifications@github.com> Sent: 22 April 2020 08:39 To: riscv/riscv-compliance <riscv-compliance@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: [riscv/riscv-compliance] Use of pseudo instructions in compliance tests. (#106) This is a discussion point - I am not clear what the correct answer is. In issue #105<#105>, I note that the regression tests use one of the assembler pseudo instructions, la, in a non-standard way. la rd, symbol is a shorthand for auipc rd, symbol[31:12] addi rd, rd, symbol[11:0] This issue is to raise the question of whether the compliance tests should use pseudo instructions at all. RISC-V is perhaps unusual in having quite so many pseudo instructions (I think there are 47 at present). As issue #105<#105> shows, not all are reliably implemented. In part they are a legacy of the attempt to bring up a compiler tool chain very quickly nearly a decade ago. Pseudo instructions are inherently opaque, and can potentially change (for example choice of insturction for nop), although this seems less likely for RISC-V, since they form part of the standard. As we discussed in the early days of the compliance standard, having to use an assembler at all is already a compromise. We are testing compliance of implementations of the architecture, not compliance of the assembler, and as we see this is an area where assemblers differ. I propose that the compliance test suite should use no pseudo instructions and stick strictly to plain assembler opcodes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#106>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA3V7ZFM4VO6IGMLMVJXJILRN2UM5ANCNFSM4MN6X2WQ>.

[aswaterman]

@simon5656 why use assembler mnemonics at all? Why use a linker? Why not just emit binary code directly?

(The linker remark is not just a flippant comment; it also deletes instructions and replaces some instructions with others, kind of like the thing you're expressing concern over.)

[allenjbaum]

I would tend to agree. It is one thing to insist that the assembler not optimize code (e.g. replace an op with a compressed version, or optimize away completely if the arguments make it a noop). But most of the uses are benign: e.g. "j label" vs "jal x0, label". The specific "la" case is usually pretty harmless as long as the assembler doesn't optimize away either of the two ops that make it up (and we stick to the standards). I'm a bit more concerned if the offset is >32 bits (in RVV64; It can even happen in RV32 with 34b physical addressing ) - I'm not sure if it tries to do a load from a constant table, or just fails.

…

On Wed, Apr 22, 2020 at 1:46 AM Andrew Waterman ***@***.***> wrote: This issue is to raise the question of whether the compliance tests should use pseudo instructions at all. IMO, this is only one step away from suggesting the compliance tests shouldn't rely on the assembler at all, and should instead rewrite its own. Inconsistencies in the documentation and implementation of pseudoinstructions should be rectified, but that's a bad reason to stop using them. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AHPXVJXBYZ6VCGA52FI5EVDRN2VHFANCNFSM4MN6X2WQ> .

[aswaterman]

FWIW, the linker can, and will, optimize away some of those addressing instructions. But that behavior can be suppressed with the —no-relax flag. On Wed, Apr 22, 2020 at 11:58 AM Allen Baum <notifications@github.com> wrote:

…

I would tend to agree. It is one thing to insist that the assembler not optimize code (e.g. replace an op with a compressed version, or optimize away completely if the arguments make it a noop). But most of the uses are benign: e.g. "j label" vs "jal x0, label". The specific "la" case is usually pretty harmless as long as the assembler doesn't optimize away either of the two ops that make it up (and we stick to the standards). I'm a bit more concerned if the offset is >32 bits (in RVV64; It can even happen in RV32 with 34b physical addressing ) - I'm not sure if it tries to do a load from a constant table, or just fails. On Wed, Apr 22, 2020 at 1:46 AM Andrew Waterman ***@***.***> wrote: > This issue is to raise the question of whether the compliance tests should > use pseudo instructions at all. > > IMO, this is only one step away from suggesting the compliance tests > shouldn't rely on the assembler at all, and should instead rewrite its own. > > Inconsistencies in the documentation and implementation of > pseudoinstructions should be rectified, but that's a bad reason to stop > using them. > > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > < #106 (comment) >, > or unsubscribe > < https://github.com/notifications/unsubscribe-auth/AHPXVJXBYZ6VCGA52FI5EVDRN2VHFANCNFSM4MN6X2WQ > > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH3XQW3B3RS6J5D6WZCNVDRN4453ANCNFSM4MN6X2WQ> .

[allenjbaum]

I actually don't know that how practical it is to remove LA or LI specifically.
IF you know the length of symbol, or of an offset, that's one thing. But compliance tests that load symbols or offsets, and until the loader figures out where things are, you may not know if an offset it 12 bits or 20 bits or 32 bits or 64 bits. To ensure consistancy, you are reduced to always assuming that those constants are 32bits (replacing them with a pair of LUI,ADDI or AUIPC,ADDI) or 64bits (which probably loads from a global constant pool using AUIPC,ADDI,LD triple).
Amusingly, tests for LUI and ADDI already contain those pseudo-ops..

If we were doing that, I'd

• modify the test spec to prohibit use of LI and LA in the tests (only; not in any other code that gets loaded),
• define LAX/LIX macros (probably need separate named versions for RV32 and RV64 when we get to tests that can switch between XLEN) that are fixed length, and globally search and replace them in all the tests in the riscv_test_suite subdirectory.

[allenjbaum]

I think the decision has been made to do precisely what is proposed above (except for the name of the LAX/LIX macros, perhaps). This will be reflected in the next merge of new tests, and a change to the test format spec.
This should be closed when that happens

[jrtc27]

Do call and tail count as pseudo-instructions? They sure aren't architectural RISC-V instructions, but there's no equivalent expanded form for either of them as they need to be adjacent with a single relocation for the pair in the ELF file, unless you do nasty things with .reloc that I don't think are supported by LLVM, only binutils.

[allenjbaum]

The prohibition of pseudo instruction in tests is intended to be in just the code in actual .S assembly language tests themselves, and not in supporting code, or directives - if that answers the question. The rationale for this is that if different toolchains generate different expansions, it may mess up how things get loaded between models - and then we've lost PC relative synch points we are depending on. The fear may be an overreaction, but - it wasn't that hard to do.

[allenjbaum]

The current tests (and not any initialization or trap handling code - just the .S files in the riscv-test-suite/RV32* and /RV64* directories now use constant length LI and LA macros to replace li and la pseudo ops, so closing this one.