The sstatus register is a subset of the mstatus register. In a straightforward implementation, reading or writing any field in sstatus is equivalent to reading or writing the homonymous field in mstatus.
This is taken from the riscv-privledeged-20211203.pdf.
We have two registers and consume different address spaces for both status for S and M modes. Also, storing information in two different registers seems more comprehensive(I guess).
So what is the reason to use sstatus as a subset of mstatus instead of a separate register? Is there any performance optimization on this?
If it is the optimized way, why does the spec allocate different register addresses?
They have different privilege levels.
In Section 2.2, you can see that sstatus has privilege SRW, meaning it can be read and written from supervisor (S) mode. On the other hand, mstatus is MRW, so it can be read and written from machine mode (M), which apparently is a higher privilege level.
So effectively, it means that S mode is only allowed access to a subset of the bits in mstatus.
An alternative way to implement this would have been to make mstatus accessible at both levels, but add extra microcode so that if it is accessed from level S, the more sensitive bits are masked off. But that would be a little more complicated. There must already be a mechanism that checks privilege level on access to any CSR register, so by treating sstatus as its own register with its own address, we can just use this existing mechanism. Once this check is passed, accesses to sstatus can simply be treated as accesses to mstatus with the sensitive bits unconditionally masked.