Need coverage for multiple of 2 integer jumps/branches in compressed test plan

[davidharrishmc]

Jumps and branches allow the target address to be a multiple of 2 rather than 4 because compressed instructions can be two bytes. However, in RV{32/64}I, there are no compressed instructions and no way to hit addresses that are not multiples of 4.

I think the best solution is to add uncompressed jal and jalr rows to the Zca tests. These should have two coverpoints consisting of rd[1] = 1 and imm[1] = 1. jalr also needs to be able to test a case where rs1+imm is odd; the bit [0] should be ignored. We need to test both rs1[0] = 1, imm[0] = 1, and rs1[0] + imm[0] = 1. See the unprivileged spec about jalr. That way these features can be tested when compressed instructions are supported, and everything else is tested in the usual I tests.

Same thing applies to branches

[Zain2050]

If we add uncompressed jal and jalr to the Zca testplan, some portion of uncompressed jal test would then be in I Extension and some would be in Zca. It will scatter the test for uncompressed jal/jalr.
What if we allow jal and jalr to get compressed by making changes in the Makefile. This way we could add c.nop instructions in the test which will eventually result in address multiples of 2. However, some jal/jalr instructions with rs1 as x1 would also get converted to compressed form as well. Those instructions would still hit uncompressed jal/jalr bins. If that's okay, then perhaps we can use that approach. Just a suggestion!

[davidharrishmc]

The guiding principle is that a user should run all of the testplans whose names match the supported extensions. In an RV32I machine, they will just run RV32I. In RV32IZca, they will run both I and Zca. jal, jalr, and the branches are different between RV32I and RV32IZca in that the destination address can be an odd multiple of 2 when Zca is supported. RV32I should not test this, but RV32Zca should test this. Later, we will add tests to RV32ZcsrExceptions to check that RV32I takes a misaligned instruction address exception when the address is an odd multiple of 2. I believe it is necessary to scatter uncompressed jal/jalr/branch tests across these two testplans because certain tests should only run when Zca is supported. I don’t understand how allowing jal/jalr to be compressed addresses this. The RV32I tests can’t contain any compressed instructions, or they won’t run on a pure RV32I machine. Also, we want to fully exercise the uncompressed instruction. Am I missing something?

…

On Oct 27, 2024, at 12:14 PM, Muhammad Zain ***@***.***> wrote: If we add uncompressed jal and jalr to the Zca testplan, some portion of uncompressed jal test would then be in I Extension and some would be in Zca. It will scatter the test for uncompressed jal/jalr. What if we allow jal and jalr to get compressed by making changes in the Makefile. This way we could add c.nop instructions in the test which will eventually result in address multiples of 2. However, some jal/jalr instructions with rs1 as x1 would also get converted to compressed form as well. Those instructions would still hit uncompressed jal/jalr bins. If that's okay, then perhaps we can use that approach. Just a suggestion! — Reply to this email directly, view it on GitHub <#258 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AR4AA365DMWTH4GX5PS65GDZ5U3RRAVCNFSM6AAAAABQUVKRYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINBQGE2DCOJZHA>. You are receiving this because you authored the thread.

[Zain2050]

Guess I didn't think about running the tests on a pure RV32I machine. This clears up everything.
I'd be happy to work on this issue, but probably from the next week as I'm a bit occupied due to my midterm exams. If that's okay, you could assign this issue to me.

[UmerShahidengr]

Good thought @Zain2050. In my opinion, this issue should be assigned to the person who has implemented jal/jalr tests for RV32/64I.
For such cases, non-multiple of 4 addresses, won't it create misaligned access fault when we jump to that address? Probably we need to enable misaligned access in order to check such cases.

[jordancarlin]

I don't think it is a misaligned access if compressed instructions are supported (which I believe is the scenario being discussed here). When compressed instructions are supported the alignment constraint is relaxed to increments of 2 instead of 4. For RV32I (without Zca) then it would be a misaligned access, but that shouldn't ever happen if the Zca tests are being run.