================
@@ -184,6 +191,37 @@ let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in {
} // hasSideEffects = 0, mayLoad = 0, mayStore = 0
} // Predicates = [HasVendorXqcia, IsRV32], DecoderNamespace = "Xqcia"
+let Predicates = [HasVendorXqciac, IsRV32], DecoderNamespace = "Xqciac" in {
+let hasSideEffects = 0, mayLoad = 0, mayStore = 0 in {
+ def QC_C_MULADDI : RVInst16CL<0b001, 0b10, (outs GPRC:$rd_wb),
+ (ins GPRC:$rd, GPRC:$rs1, uimm5:$uimm),
+ "qc.c.muladdi", "$rd, $rs1, $uimm"> {
+ let Constraints = "$rd = $rd_wb";
+ bits<5> uimm;
+
+ let Inst{12-10} = uimm{3-1};
+ let Inst{6} = uimm{0};
+ let Inst{5} = uimm{4};
+ }
----------------
lenary wrote:
Unlike the main RISC-V ISA, the Xqci architects did not want to split
instructions into (sub-)extensions by size (as you can see, they have been
split by functionality). To make the ABI much easier, they agreed that all of
the sub-extensions with any 16- or 48-bit instructions would require Zca, as
the compiler will need to be able to insert `c.nop` when aligning etc etc.
Not splitting instructions into extensions by size does mean that existing
assumptions used by `CompressPat` no longer quite hold. At the moment, it is
enough to do `.option norvc` (or an equivalent with `.option arch`) for the `C`
extension to prevent compression, but you cannot disable `qc.c.muladdi` without
disabling `qc.muladdi`, so we cannot just use architecture features to gate
compression patterns (There are even more issues around our 48-bit
instructions, which I don't want to write out here). As I said, I have been
thinking about an approach for this, but I haven't had time to work through the
patch, test it, and present it for review. This is why none of our `Xqci*`
patches so far have had `CompressPat`s, and we do not intend to add them for
the moment. Most of these issues are reasonably orthogonal to the issue that
@svs-quic mentioned in the actual tablegen code for `CompressPat`s.
https://github.com/llvm/llvm-project/pull/121037
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
