Contribute Andes's the MC layer support of P extension.
I listed extra works in this implementation
- Register class (GPRP) have vector types for 'P' instruction.
- GPRPair is a special register class with even/odd pair of registers for RV32.
Don't need a blank line above, and I'd put GPR stuff before FPR stuff.
I do not like the side-effecting function. Please make it look like the FPR code, which probably means splitting out the "is GPR pair" part from convertGPRToGPRPair (i.e. checking if it's an even register number). Also, seeing MCK_GPRPair for non-RV32 should always be an error (assertion failure), surely, and not just something to ignore?
You should not need both namespaces, only one of them. I'd put the weirdo register pair instructions in a namespace and leave the normal non-pair RV64 versions in the standard namespace.
As I said in the other review, this goes against what the RISCV spec said it would do, as it's using an encoding it proposed reserved for >32-bit instructions. I'm not a fan of merging this until it's confirmed that this is the way things are definitely going to go, as it may affect downstreams that use the >32-bit encoding space to steer clear of conflicts (like hwacha did), but maybe there aren't any for us?
Style has been to put such constraints in the body rather than a let (see A and C).
That doesn't look like a uimm6 to me
This assumes RV32, and is not clear it applies to register pairs
Needs a VT suffix, but it's not clear from the name what exactly this is
|19 ↗||(On Diff #319756)|
I've never understood why this isn't a SupportedFeatures field given processors don't grow new features but compilers do...
You don't need rvXXp- prefixes on your files if they're inside rvp. Just use rvXX- if you need to specify XLEN.
This is almost the same file as rv32p-invalid.s. Merge the common parts.
Inst with MCK_GPRPair version is still trying to match operand for non-RV32. It would be a error due to missing features later.
Do you mean that is not the same as RVPShiftI5 with uimm5. It is not uimm6 here.
Add suffix VT. Do you have any suggestion for this? Thanks.
The range for immediate is difference between RV32 and RV64.
The immediate range is difference between RV32 and RV64.
Then don't call it RVPShiftI6
XLenVEI8VT / VXLenEI8VT / XVEI8VT / PVEI8VT / VPEI8VT all come to mind, maybe others have better ideas, but I think it's important to include the fact that it's a vector in the name otherwise it just looks like a weird way to say i8.
|24 ↗||(On Diff #332574)|
Please put CHECK lines above not below
I have tried to add new types to the regular GPR class before. But it show lots of Could not infer all types in pattern! error message on building. It have to add explicit type (XLenVT in most cases) to the existed codegen patterns which use GPR. I am not sure that is a good solution.