jrtc27 added a comment. Firstly, please generate your diffs with full context (-U with a sufficiently-large number). Secondly, can we avoid having to do a bunch of duplication with some clever use of multiclasses for F/D/Zfh and pseudos? Though maybe it's small enough that the duplication is easier to reason about than an obfuscated abstracted version.
Also, do you not need more predicates? You can't just assume all of F, D and Zfh exist. As for Zfinx itself, well, the idea is fine, but I really detest the way it's being done as an extension to F/D/Zfh. Running F code on an FZfh core _does not work_ so it is not an _extension_. Instead it should really be a set of separate extensions to I/E that conflict with F/D/Zfh, i.e. Zfinx, Zdinx and Zfhinx, but apparently asking code that complies with a ratified standard to change itself in order to not break when a new extension is introduced is a-ok in the RISC-V world. ================ Comment at: llvm/test/MC/RISCV/rv32zfh-invalid.s:33 -# Integer registers where FP regs are expected -fadd.h a2, a1, a0 # CHECK: :[[@LINE]]:8: error: invalid operand for instruction - ---------------- These need to stay, but presumably instead as errors about Zfinx not being enabled? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93298/new/ https://reviews.llvm.org/D93298 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
