Why aren't post-increment loads with RD==RS1 treated as illegal?

[Silabs-ArjanB]

Why aren't post-increment loads with RD==RS1 treated as illegal?

[pascalgouedo]

Hi @Silabs-ArjanB
Don't understand your point.
rD = rs1 is just an exceptional case than needs to be explained to understand what is the design behaviour and to align the reference model to the design.
But when rD != rs1 the instruction is just doing its job...
Moreover adding illegal instruction decoding for that case would bring some complexity because it needs to compare registers contents (so using Register File and Forwarding paths). And surely timing degradation as well as this decoding would finish in cancellation signals.
And the C compiler should not generate this case anyway as it is useless.
But it could happen with randomly generated verification tests as it was discovered this way.

[Silabs-ArjanB]

Hi @pascalgouedo

Moreover adding illegal instruction decoding for that case would bring some complexity because it needs to compare registers contents (so using Register File and Forwarding paths).

I don't think you need to compare register contents at all. This is just about comparing indices.

For example cv.lb x2, (x2), Imm 'could' (and I think 'should') have been declared as illegal (as Rd == RS1 == x2). There is no need to actually read from x2 to figure this out.

And surely timing degradation as well as this decoding would finish in cancellation signals.

Declaring such instructions as illegal would not cause timing degradation in a core like the CV32E40P.

And the C compiler should not generate this case anyway as it is useless.

It is useless indeed and therefore I think it is wasteful to eat up encoding space and complicate the writeback mechanism and add additional verification effort (to check that the priority is handled correctly for a scenario that is not considered useful).

[pascalgouedo]

Yes you're right indices are enough.

About eating encoding space I don't get it because you can't reuse the "lost" case when rd = rs1 to put another instruction.

And no added design complexity either as pointer increment writeback is done from EX when load is granted while destination writeback is done from WB with loaded data.

[Silabs-ArjanB]

Although not a lot of opcode space is lost there is still some space lost. Other extensions normally treat such space as illegal instructions and it is not imaginary that these spaces get filled.

An example is the following instructions where two source operands are not allowed to be the same register: https://github.com/riscv/riscv-code-size-reduction/blob/main/Zc-specification/cm_mvsa01.adoc

It is especially not nice as now we have an encoding that has the same functionality as original RV32I loads.

[pascalgouedo]

I asked to Embecosm some precisions about generic and pulp load and about post-increment as well.

The answer is:

• CORE-V specific instructions have priority over the generic RISC-V instructions.
• Those post-incremented loads using same pointer and destination register could be generated in some cases and it would require some additional work to forbid them.

[Silabs-ArjanB]

@pascalgouedo Thank you for following up.