[PATCH] D95588: [RISCV] Implement the MC layer support of P extension

[Jim Lin via Phabricator via cfe-commits]

Jim marked an inline comment as done.
Jim added inline comments.


================
Comment at: llvm/lib/Target/RISCV/RISCV.td:186-188
+                       [FeatureExtZpsfoperand,
+                        FeatureExtZpn,
+                        FeatureExtZprvsfextra]>;
----------------
jrtc27 wrote:
> Jim wrote:
> > jrtc27 wrote:
> > > These aren't correct? RV64 doesn't have Zpsfoperand and RV32 doesn't have Zprvsfextra.
> > RV64 has Zpsfoperand extension that just has normal GPRs as operands (RV32 has even/odd paired-register operand).
> > 
> > RV32 doesn't have Zprvsfextra. All of instruction in Zprvsfextra are defined in Predicates = [HasStdExtZprvsfextra, IsRV64].
> > 
> > If P is enabled, it means Zpn+Zpsfoperand enabled on RV32, and Zpn+Zpsfoperand+Zprvsfextra enabled on RV64.
> My concern is that the internal inflexibility is going to leak out of LLVM, such as into the .riscv.attributes section, and thus produce broken binaries because they claim they need Zprvsfextra on RV32, which is an invalid combination.
> 
> And if Zpsfoperand exists for RV64 then it shouldn't be called `Paired-register operand 'P' Instructions`, because the operands are only paired on RV32.
I upload a new patch https://reviews.llvm.org/D108189 to support P extension 's arch string.
If rv32izprvsfextra (Zprvsfextra on RV32) accepted from *.s arch attribute, it emits error message to forbid this invalid combination.
Before emitting _zprvsfextra string, it would check RV64 is enabled.

If llc is given -mattr=+experimental-zprvsfextra on RV32, it would be ignored.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D95588/new/

https://reviews.llvm.org/D95588